AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren
Zurück Delphi-PRAXiS Programmierung allgemein Programmieren allgemein Kauf- und Kontenverwaltung - Datenbank notwendig?
Thema durchsuchen
Ansicht
Themen-Optionen

Kauf- und Kontenverwaltung - Datenbank notwendig?

Ein Thema von Asura · begonnen am 2. Dez 2017 · letzter Beitrag vom 14. Jan 2018
Antwort Antwort
Asura

Registriert seit: 10. Jun 2013
87 Beiträge
 
#1

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 13. Dez 2017, 09:09
Gut, denke das habe ich nun alles verstanden, dankeschön!

[QUOTE=mkinzler;1388680]
Zitat:
was für ein Tablet?


Zur Bestellabwicklung soll mein Programm auf ein Tablet übertragen werde. Bis jetzt existiert das Tablet noch nicht, ich werde es dann zu gegebenen Zeitpunkt kaufen. Wird natürlich ein Tablet mit Windows werden.
Meine Frage bezog sich darauf, ob das Programm später bei dem Release eine Access Version benötigt, bezüglich Treiber, um auf die Datenbank auf dem Tablet zuzugreifen.
  Mit Zitat antworten Zitat
Benutzerbild von p80286
p80286

Registriert seit: 28. Apr 2008
Ort: Stolberg (Rhl)
6.659 Beiträge
 
FreePascal / Lazarus
 
#2

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 13. Dez 2017, 10:35
Meine Frage bezog sich darauf, ob das Programm später bei dem Release eine Access Version benötigt, bezüglich Treiber, um auf die Datenbank auf dem Tablet zuzugreifen.
Weiter oben habe ich erfahren, daß Access ja immer bei Windows dabei ist (es sei denn es wird nicht mit installiert), dann wird es wohl verfügbar sein.

Gruß
K-H
Programme gehorchen nicht Deinen Absichten sondern Deinen Anweisungen
R.E.D retired error detector
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
2.600 Beiträge
 
Delphi 7 Professional
 
#3

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 13. Dez 2017, 11:12
Bezgl.: WIDEMEMO

Für Namen nimmt man kein Memofeld sondern 'nen String bzw. VarChar. Wie lang kann den ein "gewöhnlicher" Username werden? VarChar(250) wäre da wohl schon eher überdimensioniert. In eine Memo- bzw. Blobfeld passt notfalls auch ein ganzer Roman rein, das scheint mir doch eher reichlich übertrieben.

Könntest Du eventuell mal die Createstatements Deiner Tabellen hier posten? Dann kann man da nochmal drüberschauen, inwieweit Bedeutung und Typ der Spalten zusammenpassen. Das ist was, da kann man am Anfang schonmal sehr leicht was falsch wählen und bereut nachher, dass eine Umstellung ohne Datenverlust nicht mehr so leicht möglich ist.

Die Tabellenerstellung würd' ich insgesamt auf Dauer lieber mit dem Programm (oder einem extra Pflegeprogramm?) selbst machen. Geht auch über 'ne ADOQuery und deren Methode ExecSQL. Vorteil: Die MS-Access-typischen "Unsitten" bei der Tabellendefinition kann man dadurch umgehen (kann sich also an den SQL-Standard halten, was einen ggfls. mal notwendig werdenden Datenbankwechsel vereinfacht), außerdem bekommt man (so meine ich) ein besseres Gefühl für die Tabellendefintionen und deren Abhängigkeiten untereinander. Aber das ist sicherlich auch Geschmacksache.
  Mit Zitat antworten Zitat
Asura

Registriert seit: 10. Jun 2013
87 Beiträge
 
#4

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 13. Dez 2017, 23:23
Bezgl.: WIDEMEMO

Für Namen nimmt man kein Memofeld sondern 'nen String bzw. VarChar. Wie lang kann den ein "gewöhnlicher" Username werden? VarChar(250) wäre da wohl schon eher überdimensioniert. In eine Memo- bzw. Blobfeld passt notfalls auch ein ganzer Roman rein, das scheint mir doch eher reichlich übertrieben.

Könntest Du eventuell mal die Createstatements Deiner Tabellen hier posten? Dann kann man da nochmal drüberschauen, inwieweit Bedeutung und Typ der Spalten zusammenpassen. Das ist was, da kann man am Anfang schonmal sehr leicht was falsch wählen und bereut nachher, dass eine Umstellung ohne Datenverlust nicht mehr so leicht möglich ist.

Die Tabellenerstellung würd' ich insgesamt auf Dauer lieber mit dem Programm (oder einem extra Pflegeprogramm?) selbst machen. Geht auch über 'ne ADOQuery und deren Methode ExecSQL. Vorteil: Die MS-Access-typischen "Unsitten" bei der Tabellendefinition kann man dadurch umgehen (kann sich also an den SQL-Standard halten, was einen ggfls. mal notwendig werdenden Datenbankwechsel vereinfacht), außerdem bekommt man (so meine ich) ein besseres Gefühl für die Tabellendefintionen und deren Abhängigkeiten untereinander. Aber das ist sicherlich auch Geschmacksache.
Ich konnte das Problem lösen, indem ich die Einstellung auf einen Short String geändert habe habe.

Bezüglich des Pflegeprogramms, wollte ich eh entwerfen, da ich gerne doch eine Option hätte SQL Befehle auszuführen. Doch habe ich gerade Probleme mit der Verbindung, dass er das Ergebnis auf die das Grid überträgt. Muss man nicht die Tabelle dafür schließen und dann das Datasource an das Query anhängen?
Wie würde das dann auch mit der Formatierung aussehen wegen SQL? Benutze ein Memofeld, dort trage ich den SQL Befehl ein und über ADOQuery.Text setze ich den Text rein.

Geändert von Asura (13. Dez 2017 um 23:32 Uhr)
  Mit Zitat antworten Zitat
Delphi.Narium

Registriert seit: 27. Nov 2017
2.600 Beiträge
 
Delphi 7 Professional
 
#5

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 14. Dez 2017, 00:04
Zum Anzeigen der Ergebisse eines SQLs braucht man eigentlich nur:

Ein Memo für die Texteingabe.
Eine ADOQuery, 'ne DataSource und ein DBGrid. DBNavigator ist ein kann. Eventuell 'ne Statusbar mit SimplePanel := True;

Einen Button, der ungefähr so einen Quelltext im OnClick enthält (ungetestet):
Delphi-Quellcode:
var
  s : String;
begin
  ADOQuery.Close;
  ADOQuery.SQL.Clear;
  // Wenn selektierter Text vorhanden ist, wird nur der als SQL übernommen.
  // Dadurch kann man dann im Memo mehrere SQLs haben und muss nicht immer alle neu schreiben ;-)
  // Speichert man mit Memo.Lines.SaveToFile beim Programmende
  // und lädt beim Programmstart mit Memo.Lines.LoadFromFile, hat man auch länger was davon.
  if Memo.SelAvail then begin
    ADOQuery.SQL.Add(Trim(Memo.SelText));
  end else begin
    ADOQuery.SQL.Add(Trim(Memo.Text));
  end;
  if ADOQuery.SQL.Count = 0 then exit;
  Try
    s := AnsiLowerCase(Copy(ADOQuery.SQL[0],1,6);
    if s = 'selectthen begin
      ADOQuery.Open; // Für Abfragen
      StatusBar.SimpleText := Format('Es wurden %d Datensätze gefunden.',[ADOQuery.RecordCount]);
    end else begin
      ADOQuery.ExecSQL; // Für alles andere wie Insert, Update, Delete, Create Table ...
      StatusBar.SimpleText := Format('Von der Abfrage waren %d Datensätze betroffen.',[ADOQuery.RowsAffected]);
    end;
  except
    on e : Exception do begin
      MessageDlg(e.Message,mtError,[mbOk],0);
    end;
  end;
end;
Man kann zur Laufzeit bei 'ner DataSource den DataSet ändern, allerdings gehe ich her, dass ich jeder Query, Table (wenn ich die denn mal brauche) 'ne eigene DataSource spendiere und jeweils ein eigenes DBGrid ...

Normalerweise haben aber die "Pflegeteile" von Programmen nur eine Datenbankverbindung, eine Query, eine DataSource, ein DBGrid und einen DBNavigator. Das reicht, da man alles per SQL machen kann, was zur Datenanzeige und / oder Datenmanipulation erforderlich ist.

Mehrere Querys und/oder Tables gibt es nur, wenn unumgänglich mehrer Datenmengen zeitgleich zur Verfügung stehen müssen, bei einem Pflegeprogramm scheint mir dies nicht sinnvoll zu sein.
  Mit Zitat antworten Zitat
Asura

Registriert seit: 10. Jun 2013
87 Beiträge
 
#6

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 14. Dez 2017, 08:45
Vielen Dank für die Mühe!

Bezüglich Memo.SelAvail musste ich leider feststellen existiert nicht, habe die auch nicht hierunter http://docs.embarcadero.com/products...rls_TMemo.html gefunden.

Wie wäre es mit:
Delphi-Quellcode:
  if SQLEingabe.SelLength <> 0 then begin
    ADOQuery.SQL.Add(Trim(SQLEIngabe.SelText));
  end else begin
    ADOQuery.SQL.Add(Trim(SQLEingabe.Text));
  end;
Aber generell tut sich effektiv nichts im Memo. Ich gehe mal davon aus, dass es bestimmt an der Verlinkung der ADO Komponenten liegt.
Du hast geschrieben, dass man nur eine Verbindung, Query, Datasource und DBGrid benötigt? Also kein ADOTable?
Wie würde dann die Verbindung aussehen zwischen den Komponenten?
Weil benötigt DataSource nicht die Komponenten ADOTable ?

Geändert von Asura (14. Dez 2017 um 09:03 Uhr)
  Mit Zitat antworten Zitat
jobo

Registriert seit: 29. Nov 2010
3.072 Beiträge
 
Delphi 2010 Enterprise
 
#7

AW: Kauf- und Kontenverwaltung - Datenbank notwendig?

  Alt 14. Dez 2017, 09:03
SelAvail, SelText, SelLength ..
bezieht sich evtl auf TSynMemo, nicht auf ein normales/Standard.
Gruß, Jo
  Mit Zitat antworten Zitat
Antwort Antwort


Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:13 Uhr.
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz