Kauf- und Kontenverwaltung - Datenbank notwendig?

[Delphi.Narium]

Zitat:

Zitat von jobo (Beitrag 1388565)

Zitat:

Zitat von Delphi.Narium (Beitrag 1388563)

Die Schnittstellensoftware ist hier Teil des Betriebssystem.
..snip..
Mein Vorschlag für Access: Meist schon vorhanden (beim eigenen Rechner schnell prüfbar - sprich: kann man 'nen ODBC-Treiber für MS-Access anlegen? Wenn nein: Vergiss es!)
..

Widerspricht sich das nicht?

Treiber hin oder her, ich müsste auch für andere Systeme Treiber installieren (außer meine Delphikomponenten machen das nativ).
Access halte ich aus diversen Gründen für "exotisch" und nicht naheliegend, weder für Anfänger noch Fortgeschrittene. Naheliegendere Systeme sind nur ein paar Klicks entfernt.

Ja, der Widerspruch ist vorhanden, aber man kann leicht prüfen, ob's nun funktionieren wird oder nicht.

Access ist exotisch, wenn man es aus der Sicht der gleichnamigen Software von MS sieht. Die ist meiner Meinung nach ein Graus.

Nimmt man nur "normales" SQL, dass auch gegen jede andere Datenbank läuft, dann ist die Datenbankdatei einfach nur 'ne Datenbankdatei. Man merkt aus dem Programm heraus (egal ob als Anwendern oder Entwickler) nicht, dass da ein (wie Du sagst) Exot hinter hängt.

Welches sind bitte die "Naheliegenderen Systeme, die nur ein paar Klicks entfernt sind?"

Was muss der Laie tuen, um eine funktionierende Datenbankanwendung schreiben zu können?

Wo muss z. B. bei SQLite die DLL hin?
Wie sieht es bei embedded FireBird aus?

Kann man deren Schnittstellen ggfls. auch zeitgleich für mehrere Programme, aber unterschiedliche Datenbanken nutzen?

Kann eine Datenbank von mehreren Programmen zeitgleich genutzt werden?

Und mir ist klar: Für professionelle Software ist mein Vorschlag absoulut ungeeignet.

[Asura]

Zitat:

Zitat von jobo (Beitrag 1388523)

Zitat:

Zitat von Asura (Beitrag 1388512)

Das Programm wird nur unter Freunden (Wie anfangs beschrieben max. 16) verwendet und die Datenpflege soll nur über meinen Computer laufen.

Unter Freunden ist ein kostenloses Programm ja vielleicht eine gute Wahl. Aber vielleicht sind es ja auch reiche Freunde. Ob Du den Rest Deines Lebens nur 16 Freunde hast oder ob es ein paar mehr werden, spielt bei einer Entscheidung pro Datenbank dann letztlich keine Rolle.
Das Datenmodell sollte allerdings davon ausgehen, dass die Anzahl der Nutzer beliebig ist. Das ist hauptsächlich eine Kopfsache beim Entwurf. Man neigt zur Sparsamkeit mit dieser Zahl im Kopf und trifft falsche Entscheidungen.

Diese Anzahl der Personen kann sich jedoch nicht verändern, deswegen sprach ich von Max. 16. Also die Zahl bleibt fest.

Bezüglich der ganzen Datenbankmöglichkeiten: Also ich suche eher ein Datenbanksystem, welches die Datenbankpflege leicht macht (Sprich: In Richtung PhpMyAdmin-Oberfläche) oder in Form der Access-Datenbank, da ich auch das MS Programm zur Datenpflege habe.
Nur ein Gerät (Tablet) wird das Programm besitzen, darüber können dann die maximal 16 Benutzer zugreifen und ich kann dann über ein anderen Computer auf diese Datenbank zugreifen.

Ich dachte anfangs ja einfach an Textdateien, die mit einer Cloud gesichert werden und somit mir auch zugänglich sind. Doch sehe ich ein, dass eine Datenbank, auch in hinblick auf eventuelle Analysefunktionen und erweiternde Programme zur Analyse und Bearbeitung, eher sinnvoll wäre.

[jobo]

@Delphi.Narium
Access möchte z.B. gerne diese häßliche Klammerung bei Objektnamen, nicht Standard.
Aber ich will nicht weiter drauf rumreiten.
Vielleicht ist ja auch die Installation einer sqlite dll ein Problem. Z.B. auf einem Tablet, womit man beim nächsten Beitrag des TE wäre.

Ich gehe mal davon aus, es ist ein Windows Tablet?

Eine komfortable Oberfläche bietet Access natürlich, das kann MS ganz gut.
Etwas wie PHPMyAdmin bieten auch Firebird oder Postgres, für sqlite bekommt man es auch als Browserplugin (Keine Ahnung, wieviele davon unter FF seit Version 57 noch laufen).
Frage wäre auch, was alles so als "Pflege" anfällt.

[Delphi.Narium]

Die hässliche Klammen braucht aber nur die Software von MS, habe das noch bei keiner Delphiapplikation, die u. a. Access-Datenbanken nutzt, benötigt.

Ohne die MS-Oberfläche funktioniert auch Standard-SQL. Nichts mit []`´ und was die per Software meinen alles nutzen zu müssen.

Als "Oberfläche" brauch' ich eigentlich nur:

Ein Memo für die Eingabe von SQL, eine Abfragekomponente, um eben diese auszuführen. Ein DBGrid für die Anzeige der Daten und 'nen TDBNavigator für das Navigieren durch die Datenmenge. Alles, was darüberhinaus benötigt wird, macht einen abhängig von irgendeinem System und ruiniert ggfls die Datenbankunabhängigkeit. (Ja, ist überspitzt formuliert ;-))

Für FireBird könnte man FlameRobin nehmen, muss dann aber die FireBird-Servervariante nutzen, embedded geht (soweit ich weiß) nicht.

Klar: Bei SQLite kommt die DLL zur Exe und gut is, bei FireBird braucht man für die Embeddedversion schon was mehr.

Da beim TE Access als Software zur Verfügung steht, bietet sich das meiner Meinung nach an. Man kann einerseits ein Programm mit Delphi schreiben, was die Ganze zu lösende Aufgabe "abwickelt". Für Zweifelsfälle oder das einmalige Erstellen der Tabellen, kann man aber die MS-Software nutzen. Solange man sich bei den Tabellen- und Spaltennamen an den Standard hält, ist das unproblematisch. Wer Sonderzeichen, Leerzeichen ... meint in den Tabellendefinitionen nutzen zu müssen, gehört eh gehauen ;-) und macht es sich schwer, wenn irgendwann mal die Datenbank (aus welchen Gründen auch immer) ausgetauscht werden muss.

[haentschman]

Moin...:P
Auf die Gefahr hin, mir wieder den Mund zu verbrennen... 8-)

Zitat:

Ein Memo für die Eingabe von SQL, eine Abfragekomponente, um eben diese auszuführen.

SQL im Klartext einzugeben ist keine gute Idee. Erst Recht für den User. Siehe SQL Injection.

Zitat:

Ein DBGrid für die Anzeige der Daten und 'nen TDBNavigator für das Navigieren durch die Datenmenge.

...lasse ich mit Ach und Krach durchgehen. :zwinker:

Zitat:

Alles, was darüberhinaus benötigt wird, macht einen abhängig von irgendeinem System und ruiniert ggfls die Datenbankunabhängigkeit. (Ja, ist überspitzt formuliert )

Überspitzt ist kein Ausdruck... :zwinker: Wie kommst du denn darauf? Es gibt haufenweise Techniken die auch die datensensitiven Controls überflüssig machen. Denn die machen dir die Optik der Oberfläche zur Sa..., weil diese nicht als DB Version vorliegen.

Zitat:

Für FireBird könnte man FlameRobin nehmen, muss dann aber die FireBird-Servervariante nutzen, embedded geht (soweit ich weiß) nicht.

Zitat:

if you don't have a host name, because yours is a local or embedded Firebird server

...:P

Zitat:

Klar: Bei SQLite kommt die DLL zur Exe und gut is, bei FireBird braucht man für die Embeddedversion schon was mehr.

3 DDL´s...Der Vorteil ist, das man bei Firebird mit der gleichen Datenbank sowohl Embedded als auch mit dem Server Multi User arbeiten kann.

Zitat:

Da beim TE Access als Software zur Verfügung steht, bietet sich das meiner Meinung nach an.

Um Gottes Willen. :roll: Wer behauptet Access sei eine Datenbank sagt auch jeden Tag "Jehowa" und bettelt darum gesteinigt zu werden. :stupid:

Zitat:

Man kann einerseits ein Programm mit Delphi schreiben, was die Ganze zu lösende Aufgabe "abwickelt".

...so soll es sein. :thumb:

Zitat:

Für Zweifelsfälle oder das einmalige Erstellen der Tabellen, kann man aber die MS-Software nutzen. Solange man sich bei den Tabellen- und Spaltennamen an den Standard hält, ist das unproblematisch.

Bei SQL ist der Standard (SQL-92) das Non plus Ultra! Da weicht Access schon mal ab.

Zitat:

wenn irgendwann mal die Datenbank (aus welchen Gründen auch immer) ausgetauscht werden muss.

Das ist mit Access in naher Zukunft zu erwarten, weil die Anforderungen meistens über die erste Vorstellung hinausgehen.


Letztendlich entscheidet der Umfang der Anwendung über das DBMS. Im Moment sind es 16 User...

Zitat:

darüber können dann die maximal 16 Benutzer zugreifen

...das sieht nach einem Mehrbenutzersystem aus. Da scheidet Access schon mal aus. :wink:

Zitat:

und ich kann dann über ein anderen Computer auf diese Datenbank zugreifen

Wie kannst du sicherstellen, daß kein anderer User gleichzeitig zugreift? :wink:

Bis bald... :hi:

[Asura]

Zitat:

Zitat von haentschman (Beitrag 1388599)

Zitat:

darüber können dann die maximal 16 Benutzer zugreifen

...das sieht nach einem Mehrbenutzersystem aus. Da scheidet Access schon mal aus. :wink:

Zitat:

und ich kann dann über ein anderen Computer auf diese Datenbank zugreifen

Wie kannst du sicherstellen, daß kein anderer User gleichzeitig zugreift?

16 Benutzer können über ein Gerät nur auf das Programm zugreifen, nicht auf die Datenbank!
Auf die Datenbank soll nur ich über meinen Computer Zugriff darauf haben, um dort eventuell Datensätze anzupassen/löschen oder dergleichen.
Also, ich möchte das nur gerne sehr simpel haben und Systeme wie PHPmyAdmin, Access sind für mich simpel. Ohne große SQL Befehle, wenn ich nur mal Tabellen und/oder Datensätze ändern möchte.

[Delphi.Narium]

Zitat:

Zitat von haentschman (Beitrag 1388599)

Moin...:P
Auf die Gefahr hin, mir wieder den Mund zu verbrennen... 8-)

Zitat:

Ein Memo für die Eingabe von SQL, eine Abfragekomponente, um eben diese auszuführen.

SQL im Klartext einzugeben ist keine gute Idee. Erst Recht für den User. Siehe SQL Injection.

Ich schrieb für mich und nicht für den User!!!
Außerdem handelt es sich dabei dann nicht um SQL Injection, sondern um fehlerhafte oder falsche oder ungeeignete oder systemzerstörenden SQLs. Aber nicht um "hinterherum" manipulierte Abfragen. SQL-Injection ist: Wenn ich ein vorhandenes SQL, auf das ich direkt keinen Einfluss habe, durch Parametermanipulation und/oder Ausnutzung von Softwareschwachstellen, ein SQL mache, dass der eigentlichen Nutzung zuwiderspricht. Die Eingabe eines SQL-Statments zwecks Ausführung, ist kein SQL-Injection.
Ansonsten wäre ja jedes SQL, das ich in FlameRobin bei "Execute SQL Statement" eingebe, eine SQL-Injection, dito. bei der Nutzung von TOAD für Oracle ...

Zitat:

Zitat von haentschman (Beitrag 1388599)

Zitat:

Ein DBGrid für die Anzeige der Daten und 'nen TDBNavigator für das Navigieren durch die Datenmenge.

...lasse ich mit Ach und Krach durchgehen. :zwinker:

Auch hier: Für mich, für die Entwicklung und nicht für den User!!!

Zitat:

Zitat von haentschman (Beitrag 1388599)

Zitat:

Alles, was darüberhinaus benötigt wird, macht einen abhängig von irgendeinem System und ruiniert ggfls die Datenbankunabhängigkeit. (Ja, ist überspitzt formuliert )

Überspitzt ist kein Ausdruck... :zwinker: Wie kommst du denn darauf? Es gibt haufenweise Techniken die auch die datensensitiven Controls überflüssig machen. Denn die machen dir die Optik der Oberfläche zur Sa..., weil diese nicht als DB Version vorliegen.

Ob und wie ich die Daten anzeige, steht auf 'nem anderen Blatt, dass ist (auch mit datenbansensitiven Komponenten) datenbankunabhängig. Kein Control greift selbständig direkt auf die Datenbank zu.

Zitat:

Zitat von haentschman (Beitrag 1388599)

Zitat:

Für FireBird könnte man FlameRobin nehmen, muss dann aber die FireBird-Servervariante nutzen, embedded geht (soweit ich weiß) nicht.

Zitat:

if you don't have a host name, because yours is a local or embedded Firebird server

...:P

Zitat:

Klar: Bei SQLite kommt die DLL zur Exe und gut is, bei FireBird braucht man für die Embeddedversion schon was mehr.

3 DDL´s...Der Vorteil ist, das man bei Firebird mit der gleichen Datenbank sowohl Embedded als auch mit dem Server Multi User arbeiten kann.

Zitat:

Da beim TE Access als Software zur Verfügung steht, bietet sich das meiner Meinung nach an.

Zitat:

Zitat von haentschman (Beitrag 1388599)

Um Gottes Willen. :roll: Wer behauptet Access sei eine Datenbank sagt auch jeden Tag "Jehowa" und bettelt darum gesteinigt zu werden. :stupid:

Nochmal: Zum professionellen Einsatz nicht geeignet. Wer Office hat und dort Access nutzt, hat damit nunmal eine Datenbank. Ob die nun jedem Profi gefällt, steht doch auf 'nem anderen Blatt.

Zitat:

Zitat von haentschman (Beitrag 1388599)

Zitat:

Man kann einerseits ein Programm mit Delphi schreiben, was die Ganze zu lösende Aufgabe "abwickelt".

...so soll es sein. :thumb:

Zitat:

Für Zweifelsfälle oder das einmalige Erstellen der Tabellen, kann man aber die MS-Software nutzen. Solange man sich bei den Tabellen- und Spaltennamen an den Standard hält, ist das unproblematisch.

Bei SQL ist der Standard (SQL-92) das Non plus Ultra! Da weicht Access schon mal ab.

Wenn ich eine Access.mdb nutze ohne die MS-Oberfläche zu nutzen, kann ich mich an das Non plus Ultra! halten, ohne Probleme!!!

Zitat:

Zitat von haentschman (Beitrag 1388599)

Zitat:

wenn irgendwann mal die Datenbank (aus welchen Gründen auch immer) ausgetauscht werden muss.

Das ist mit Access in naher Zukunft zu erwarten, weil die Anforderungen meistens über die erste Vorstellung hinausgehen.

Sagen wir mal so: Solange ich Access kenne, wird es bald nicht mehr existieren. So seit 20 Jahren?
Die BDE war auch mal "die Datenbankschnittstelle" für Delphi und ist längst Schnee von gestern. Auch DBase war mal "das" relationale Datenbanksystem für PC. Kennt das noch wer? Nein, Schnee von gestern. Das Problem habe ich letztlich mit allem in der EDV.
Wird es Delphi "immer" geben? Keine Ahnung, hoffen wir es.

Zitat:

Zitat von haentschman (Beitrag 1388599)

Letztendlich entscheidet der Umfang der Anwendung über das DBMS. Im Moment sind es 16 User...

Zitat:

darüber können dann die maximal 16 Benutzer zugreifen

...das sieht nach einem Mehrbenutzersystem aus. Da scheidet Access schon mal aus. :wink:

Zitat:

und ich kann dann über ein anderen Computer auf diese Datenbank zugreifen

Wie kannst du sicherstellen, daß kein anderer User gleichzeitig zugreift? :wink:

Es ist kein Mehrbenutzersystem: Der TE schrieb klar und deutlich: Ein Gerät, ein Tablet. Da geht Mehrbenutzersystem nicht! Alle User benutzen das gleiche Gerät, dadurch habe ich zwar mehrere Benutzer aber noch lange kein Mehrbenutzersystem (zumindest hab' ich bisher darunter was anderes verstanden ;-))

Und Access kann Mehrbenutzer, habe das (wenn auch sehr ungern, eben aus Deinen Gründen) trotzdem für ein paar Kunden meines Arbeitgebers so umsetzen müssen. Und es lief: problemlos und wartungsfrei! (Und auf so 'ne Idee wäre ich freiwillig nie von alleine gekommen!)

Und nochmal nein: Für den professionellen Einsatz nicht geeignet!!!

Und langsam gehen wir vom Thema ab: Es wird eine Grundsatzdiskussion, die einem Anfänger nicht wirklich bei der Entscheidungsfindung hilft. Man kann Access nutzen, muss es aber nicht, es ist eine möglich Option, die man meiner Meinung nach unter Umständen in Betracht ziehen könnte. Diese Ansicht muss man nicht teilen.

Dem TE bleibt es überlassen für sich zu entscheiden, ob diese Möglichkeit für ihn in Betracht kommen könnte oder ob die Argumente dagegen seiner Sicht nach überwiegen. Dann muss er sich für was anderes entscheiden.

Nach dem letzten Beitrag des TE scheint mir hier Access eine durchaus sinnvolle Einstiegsmöglichkeit in die Datenbankprogrammierung. Es ist alles, für die Nutzung der Datenbank und die Entwicklung einer eigenen Software benötigte, vorhanden. Es muss nichts installiert werden, kein Lernaufwand für weitere Software, Oberflächen, Datenbankkonfiguration ...
Hätte ich mit so wenig Aufwand meine ersten Schritte bei der Datenbankentwicklung mit Delphi machen können, wäre ich erstmal zufrieden gewesen.
Bleibe bei der Meinung (trotz aller berechtigter Kritik): Für den Einstieg reicht das aus.

Und wenn es Access irgendwann nicht mehr gibt, ist es auch nicht mehr Teil von MS-Office. Ja: Dann muss man sich Gedanken über ein neues oder anderes Datenbanksystem machen. Wer garantiert uns, dass es dann FireBird, SQLite ... noch gibt?

[mkinzler]

Die Oberfläche hat nichts mit der Datenbank zu tun. Mit der Access-Oberfläche kann man auch auf andere Datenbanksysteme (MSSQL, FireBird, ..) zugreifen und es gibt auch ähnliche Programme für diese.
Sollen mehrere (gleichzeitig) auf die Daten zugreifen können (direkt) fällt Access/SQLite (ohne middleware) dann raus.
JET (das, was man oft als Access bezeichnet) ist möglicherweise vorinstalliert, gehört aber nicht zum Betriebssystem. SQlite im Gegensatz ist Teil einiger Betriebssysteme (iOS, macOS, Android).

[Asura]

Ich habe mich mal an den Access-Versuch ran gemacht.
Funktioniert super, schnell und einfach! Verbindung ist aufgebaut, testweise eine Tabelle als Form in das Programm und er zeigt mir direkt die Einträge in der Datenbank an, die ich vorher über Access hinzugefügt habe.

Ein paar Verständnisfragen kamen hier dennoch auf:

1. 
   Mir ist nur gerade aufgefallen, wenn ich über das Programm auf die Datenbank zugreife und ich nebenbei einen Eintrag mache und dann die Datei abspeichere, müsste es doch zu Überschneidungen kommen? Nach dem Motto: Das Programm möchte die Datei ändern, durch eine Eintragung, aber ich speichere eine ältere Datenbank ab, um meine neue Änderung manuell zu verwirklichen.
2. 
   Und liege ich da richtig, wenn ich später mein Programm auf dem Tablet habe, darauf ja auch die Datenbank, damit das Programm darauf zugreifen kann, aber diese Datenbank in einem Cloud-Ordner sich befinden muss, damit ich über meinen Computer auf die Datenbank zugreifen kann?
   
3. 
   Kann man eigentlich, solche Komponenten wie ADOConnection etc. irgendwie nicht auf der Form haben? Ich habe die schlichtweg auf die Form gelegt, aber ich finde das eher unschön.
   
4. 
   Des Weiteren habe ich nun die Komponenten ADOConnection, ADOTable und Datasource, reicht dies für mein Vorhaben?
   Also auch hier wieder: Sehe ich das richtig, wenn ich bei mehreren Tabellen zur Laufzeit einfach nur den Tablename von ADOTable ändern muss, um damit zu arbeiten?
   
5. 
   Mir ist noch was aufgefallen, trotzt der neuesten Version von Delphi kann ich nicht die neueste Version von Access Dateien nutzen (accdb), sondern muss auf (mdb) zurückgreifen, woran liegt das?

[Delphi.Narium]

Zitat:

Zitat von Asura (Beitrag 1388613)

Ich habe mich mal an den Access-Versuch ran gemacht.
Funktioniert super, schnell und einfach! Verbindung ist aufgebaut, testweise eine Tabelle als Form in das Programm und er zeigt mir direkt die Einträge in der Datenbank an, die ich vorher über Access hinzugefügt habe.

Ein paar Verständnisfragen kamen hier dennoch auf:

1. 
   Mir ist nur gerade aufgefallen, wenn ich über das Programm auf die Datenbank zugreife und ich nebenbei einen Eintrag mache und dann die Datei abspeichere, müsste es doch zu Überschneidungen kommen? Nach dem Motto: Das Programm möchte die Datei ändern, durch eine Eintragung, aber ich speichere eine ältere Datenbank ab, um meine neue Änderung manuell zu verwirklichen.

Du schriebst: Ein Gerät, ein Benutzer.
Da musst Du Dich dran halten.
Entweder mit dem Programm auf die Datenbank zugreifen, oder mit Access oder mit Delphi, aber nicht mit allen dreien gleichzeitig, das sind dann mehrere Benutzer und Du musst Dir Gedanken über ein Mehrbenutzerkonzept machen, wenn jede Software zeitgleich was ändern soll. Ggfls. gewinnt, wer zuletzt eine Datenänderung schreibt.

Zitat:

Zitat von Asura (Beitrag 1388613)

Und liege ich da richtig, wenn ich später mein Programm auf dem Tablet habe, darauf ja auch die Datenbank, damit das Programm darauf zugreifen kann, aber diese Datenbank in einem Cloud-Ordner sich befinden muss, damit ich über meinen Computer auf die Datenbank zugreifen kann?

Du musst die Datenbank dann irgendwie vom Tablet zu PC bekommen (und auch wieder zurück) oder dafür sorge tragen, dass sie an einer Stelle liegt, an der beide Systeme darauf zugreifen können. Aber dabei dürfen dann keine lokalen Kopieen existieren, sonst gehen ggfls. Änderungen verloren, weil die Kopieen ja nicht inhaltlich synchronisiert werden.

Zitat:

Zitat von Asura (Beitrag 1388613)

Kann man eigentlich, solche Komponenten wie ADOConnection etc. irgendwie nicht auf der Form haben? Ich habe die schlichtweg auf die Form gelegt, aber ich finde das eher unschön.

Ja kann man, man muss sie zur Laufzeit erstellen. Damit geht dann der Komfort der Entwicklungsumgebung verloren. Und stören die in der Entwicklungsumgebung wirklich so arg?

Zitat:

Zitat von Asura (Beitrag 1388613)

Des Weiteren habe ich nun die Komponenten ADOConnection, ADOTable und Datasource, reicht dies für mein Vorhaben?
Also auch hier wieder: Sehe ich das richtig, wenn ich bei mehreren Tabellen zur Laufzeit einfach nur den Tablename von ADOTable ändern muss, um damit zu arbeiten?

Scheint so, sonst würde das, was Du hast, ja nicht funktionieren. Ohne genaue Beschreibung dessen, was Du denn nun jetzt wirklich vorhast, kann man da nicht zu vielem Raten. Sollen immer nur die Daten aus einer Tabelle angezeigt werden oder ggfls. auch mal aus mehreren Tabellen? Sollen Inhalte einer Tabelle ggfls. als Nachschlagwerte für andere Tabellen dienen ...

Zitat:

Zitat von Asura (Beitrag 1388613)

Mir ist noch was aufgefallen, trotzt der neuesten Version von Delphi kann ich nicht die neueste Version von Access Dateien nutzen (accdb), sondern muss auf (mdb) zurückgreifen, woran liegt das?

Das liegt nicht an Delphi, sondern an dem genutzten Datenbanktreiber.
Siehe: https://support.office.com/de-de/art...c-7528b9f074b6

Benötigst Du für Deine Anwendung alles das, was accdb zusätzlich zu mdb bietet?

Überleg' Dir bitte zuerst, was Du genau machen möchtest und halte das irgendwie fest. Dann kannst Du gezielt fragen, was Du wie genau umsetzen kannst. Mit dem bisherigen Input ist eine effektive Hilfestellung nicht möglich.

[Asura]

Gut, ich habe mir überlegt, dass ich über eine Ini-Datei, den Zugriff solange verweigere auf die Software, wenn ich diese Datenbank über meinen Computer bearbeite.

Nun frage ich mich, wie ich nun ein Datensatz abfrage, so kann ich ja theoretisch über SQL eine Spalte abfragen, doch wie kann ich die Abfrage in ein Stringlist fassen?

Code:

 with ADOQuery do
  begin
    Close;
    SQL.Clear;
    SQL.Add('SELECT username FROM users') ;
    Open;
  end;

[Delphi.Narium]

Weiß zwar nicht, was Du vorhast, eventuell sowas?

Delphi-Quellcode:

var
  sl : TStringList;
begin
  sl := TStringList.Create;
  ADOQuery.Close;
  ADOQuery.SQL.Clear;
  ADOQuery.SQL.Add('SELECT username FROM users') ;
  ADOQuery.Open;
  while not ADOQuery.EoF Do begin
    sl.Add(ADOQuery.Fields[0].AsString);
    ADOQuery.Next;
  end;
  ADOQuery.Close;
  // Irgendwas mit der Stringliste machen.
  ...
  sl.Free;
end;

Statt 'ner Stringliste könnte man dort auch von 'ner TComboBox die Eigenschaft Items nehmen. Dann sieht die entsprechende Zeile so aus:

Delphi-Quellcode:

ComboBox1.Items.Add(ADOQuery.Fields[0].AsString);

An Stelle von

Delphi-Quellcode:

 sl := TStringList.Create;

wäre dann eher ein

Delphi-Quellcode:

ComboBox1.Items.Clear;

angebracht.

[Asura]

Ich würde gerne die existierenden Benutzer in Button.Caption speichern. Hatte das vorher ebenfalls mit Ini-Dateien gelöst, hat auch wunderbar geklappt (Buttons, weil ein Tablet und größere Buttons mit Benutzer-Auswahl angenehmer ist als eine Combobox beispielsweise).

Leider stößt er mit deinem Beispiel folgende Fehlermeldung aus:
"1 Parameter wurde erwartet, aber es wurden zu wenige Parameter übergeben".

Habe die Stringlist nur über ein Showmessage ausgeben wollen, um zu sehen, ob es funktioniert.
Ich habe auch überprüft die Verbindung von ADOQuery zu DataSource steht, sowie auch die Verbindung von DataSource zu ADOTable, also in den Objektinspektor ist alles richtig eingestellt. Komischerweise hat es ja auch mit dem Grid wunderbar funktioniert!

[Asura]

Des Weiteren habe ich mir mal bisschen mehr Gedanken zu der Datenbankmodellierung gemacht und bisschen auch mich weiter informiert über Datenbanken.

Nun möchte ich Fragen, ob hier ein Denkfehler drin ist:

Es existieren 3 Tabellen: Getränke, Bestellungen, Users

Getränke <-- n --- m --> Bestellungen <-- n --- 1 --> Users

Tabelle Getränke hat die Attribute:

Getränkename (Primärschlüssel)
Preis

Tabelle Bestellungen hat die Attribute:

Bestellt_Nr (Primärschlüssel)
Datum (Sekundärschlüssel)
UserID (Fremdschlüssel)
Getränkename (Fremdschlüssel)

Tabelle Users hat die Attribute:

UserID (Primärschlüssel)
User
Guthaben

Ist das so korrekt?

Nun noch eine Frage: Wie löse ich das, dass Bestellungen mehrere Getränke notiert und hierbei die einzelnen Getränke mit Anzahl und Preis berücksichtigt.
Lass mich raten: Mehr Tabellen und Verknüpfungen?

Ich möchte noch mal eventuell kurz Erklären was mein Vorhaben ist, damit man sich besser hineinversetzen kann:
Stellen Sie sich vor, Sie können hier einfach über ein Tablet Ihr Konto auswählen. Daraufhin öffnet sich eine Übersicht, wo verschiedene Getränke zur Auswahl stehen mit Preis (Also Konto, Getränke und Preis können variabel über die Datenbank geändert werden und werden auch so vom Programm immer mit verändert). Daraufhin kann man Beispielsweise: Zwei Bier und Zwei Cola auswählen und es wird in einen virtuellen Warenkorb gelegt. Danach drückt man nur noch Kauf abschließen und das System rechnet automatisch nach der Buchung ein Minusbetrag (Hier in der Tabelle User unter Guthaben) den Preis runter und registriert für eine spätere Einsicht immer noch (unter Tabelle Bestellungen) die komplette Bestellung.
So kann ich durch ein Programm schlichtweg Lagerbestände kontrollieren, der User hat hier immer eine Übersichtsmöglichkeit und die Sicherheit, dass keine Verrechnungen stattfinden.

Hoffe nun kommt mein Vorhaben besser rüber.

[Delphi.Narium]

Du schriebst 16 Nutzer. Folgt daraus 16 Buttons?

Wenn ja, dann sowas? (Dabei gehen wir mal davon aus, dass die Buttons Button1 bis Button16 heißen.)

Delphi-Quellcode:

var
  i   : Integer;
  btn : TButton;
begin
  ADOQuery.Close;
  ADOQuery.SQL.Clear;
  ADOQuery.SQL.Add('SELECT username, UserID FROM users') ;
  ADOQuery.Open;
  i := 0;
  while not ADOQuery.EoF Do begin
    i := i + 1;
    // So kurz ist das mutig. Man sollte im "richtigen" Programm dann prüfen,
    // ob die Komponente auch gefunden wurde und ob der Typ passt.
    btn := TButton(Self.FindComponent('Button' + IntToStr(i)));
    if Assigned(btn) then begin
      btn.Caption := ADOQuery.Fields[0].AsString;
      // Nur als Idee: Der Button "weiß" dann direkt die UserID für die weitere Arbeit.
      // Beim Button-Click muss man dann nicht erst aus dem Namen in der Caption    
      // die UserID suchen, um sie für die Tabelle Bestellungen verwenden zu können.
      btn.Tag := ADOQuery.Fields[1].AsInteger;
    end else begin
      // Das sollte nicht vorkommen, aber eine entsprechende Fehlerbehandlung
      // wäre trotzdem nicht schädlich.
    end;
    ADOQuery.Next;
  end;
  ADOQuery.Close;
end;

Zum Datenmodell:

Der Getränketabelle würd' ich zusätzlich eine Getraenke_ID gönnen und die als Primärschlüssel nehmen.

Die Tabelle Bestellungen erhält dann statt des Getränkenamens die Getränkeid.

Mit dem Modell kann man eigentlich schon pro Bestellung mehrere Getränke verwalten. Es werden dann pro Bestellung mehrere Datensätze angelegt. Man könnte, damit es übersichtlicher wird, der Getränketabelle noch eine Spalte Position spendieren. Jedes Getränk zu einer Bestellung bekommt eine eigene Position, so dass man aus Bestellt_Nr und Position einen eindeutigen Schlüssel machen könnte. Auch kann man hierüber die Ausgabe immer sortiert ausgegeben werden und hat immer die gleiche Sortierung, selbst dann wenn man mal die Getränkenamen ändern sollte.

Umlaute in Tabellen- und Spaltennamen finde ich kritisch. Man weiß nie genau, ob man das auch (wenn nötig) auf eine andere Datenbank übertragen kann. Persönlich nehme ich nur (auch wenn Datenbanken was anderes können) nur die Buchstaben A bis Z, die Ziffern 0 bis 9 und den Unterstrich _. (Mag altmodisch sein, aber bisher hat noch jeder Datenbankwechsel ohne Programmänderungen oder Änderungen am Datenmodell funktioniert. Tabellen und Spaltennamen sind bei mir maximal 30 Zeichen lang. In der Regel reicht das auch aus.

[mkinzler]

Statt

Delphi-Quellcode:

  ADOQuery.Close;
  ADOQuery.SQL.Clear;
  ADOQuery.SQL.Add('SELECT username, UserID FROM users') ;

kann man auch kurz

Delphi-Quellcode:

ADOQuery.SQL.Text := 'SELECT username, UserID FROM users;';

schreiben.

[mkinzler]

Zitat:

Tabelle Getränke hat die Attribute:

Getränkename (Primärschlüssel)
Preis

Tabelle Bestellungen hat die Attribute:

Bestellt_Nr (Primärschlüssel)
Datum (Sekundärschlüssel)
UserID (Fremdschlüssel)
Getränkename (Fremdschlüssel)

Tabelle Users hat die Attribute:

UserID (Primärschlüssel)
User
Guthaben

Ich würde es eher so machen

Getraenke:

ID (Primärschlüssel)
Name

Preise:

ID (Primärschlüssel)
getraenk (Fremdschlüssel)
von (Datum)
[bis (datum)]
Preis

Bestellungen:

ID (Primärschlüssel)
Nr
Datum
UserID (Fremdschlüssel)
Getraenk (Fremdschlüssel)

Users:
ID (Primärschlüssel)
Name
[Guthaben]

So kann man Preisänderungen besser protokollieren.

[jobo]

Zum Datenmodell noch einige Anmerkungen:
Feldnamen in einheitlicher Sprache, Englisch ist quasi Standard
Bei Feldnamen einer einheitlichen Nameskonvention für Schlüsselfelder, Flags, Logikattributen folgen
Primärschlüssel wie schon genannt als Zahlwert, Namen (änderbar) als separates Feld, ebenfalls unique
Tabellen und Feldbezeichnungen möglichst passend, aber allgemein wählen. Spätestens wenn die Leute auch Snickers und Twix bestellen, ist Getränkename unglücklich gewählt, also z.B. Tabelle "Produkt", Feld "Name"
Schlüsselwerte am besten für alle Tabellen über eine zentrale Sequenz erzeugen.
Datenmodel-Constraints (unique, not null, ref constraints, ..) möglichst eng fassen und bei Bedarf lockern oder Ausnahmen definieren.
Cascading Constraints mit Vorsicht (oder gar nicht einsetzen), bwahrt Entwickler/Anwender vor Datenverlust.

16:
Ich hoffe, es werden nicht 16 Buttons!
Man braucht viele z.B. 27 Buttons für die Buchstaben einer virtuellen Tastatur, 10 für die Ziffern des Nummernblocks usw., aber nicht für verschiedene User. Bitte diese Zahl vergessen - auch wenn sie eine Marke für die "Dimension" des Projekts ist!
In dem Moment, wo man in solchen Kategorien denkt, geht das Design (des Datenmodells oder der GUI/der Logik) leicht in die Hose.

[mkinzler]

Ware statt Getränke, Vorgang statt Bestellungen ( dann kann man auch "Guthabenzugänge" modellieren und das aktuelle Guthaben berechnen)

Zitat:

Schlüsselwerte am besten für alle Tabellen über eine zentrale Sequenz erzeugen.

Oder pro Tabelle. Bei Access geht dies ja sowiso auch nicht anders.

[Bernhard Geyer]

Zitat:

Zitat von HolgerX (Beitrag 1388546)

Alles für die Erstellung/Benutzung einer Access-Datenbank ist auf einem blanken Windows-Rechner schon vorhanden.
...
Oder habe ich da was verpasst? ;)

Jo, hast du.
MS ist zwar auf "normalen" Windows-Systemen vorhanden, aber nicht immer.
Im Berech Embededd ist die Jet-Engine ein Optionaler Teil den man (um Platz zu sparen) auch abwählen kann.
MS hat (früher) die Jet-Engine auch im Rahmen der MDAC-Installation verteilt. Die letzten Versionen waren aber ohne dieser bereit gestellt.

Ich vermute das MS die Jet-Engine deshalb nicht ausbaut um nicht noch eine (unnötige) Problemstelle zu produzieren (wie sie ja an anderen Stellen mit "komischen" Entscheidungen sich ohne Not erschaffen haben.
Darauf würde ich mich nicht verlassen. In Zeiten von "Mobile First" kann sowas auch mal ohne Vorankündigung in einem Spring/Autum-Update kommen.

[Asura]

Zitat:

Zitat von Delphi.Narium (Beitrag 1388641)

Du schriebst 16 Nutzer. Folgt daraus 16 Buttons?
Wenn ja, dann sowas? (Dabei gehen wir mal davon aus, dass die Buttons Button1 bis Button16 heißen.)

An sich funktioniert das System, jedoch wenn er auf den Namen des Benutzers zugreifen will, gibt er mir eine Fehlermeldung aus. mit der ID funktioniert es aber.
Ich habe mal ein DBGrid in die Form gelegt und dort die Tabelle reingeladen. Er lädt in das Feld User überall das Wort "WIDEMEMO", ich gehe mal davon aus, das ist der Grund, warum er die Fehlermeldung rauswirft, die ich weiter oben angegeben habe?

Zitat:

Zitat von mkinzler (Beitrag 1388660)

Ich würde es eher so machen

Was bedeuten die Attribute mit den eckigen Klammern?
Warum existiert bei Tabelle Bestellungen einmal ID und einmal Nr. Ist beides nicht eineindeutig? BestellNr kann doch auch nur einmal in Tabelle Bestellungen vorkommen?

Ich verstehe auch noch nicht so ganz, wie eine Bestellung mehrere Getränke enthalten kann und wie berechnet er den Gesamtwert einer Bestellung?

Bis jetzt lese ich die Datenbank wie folgt:
Es existieren zwei Getränke (Beispielsweise) in der Tabelle Getraenke.
und es sind jeweils zwei Einträge in Preise für Getraenke hinterlegt.
Es existiert ein Benutzer mit einem Guthaben von +10€. Nun bestellt er über die Software etwas, und es wird ein Eintrag mit der Bestell Nur, Datum, dann der UserID und von nur einem Getränk der Name genommen.
Die Kosten zu dem Datenmodell einer Bestellung kann man ja aus dem Preis des einen Getränks aus der Tabelle Preise beziehen.

Deswegen meine Frage: Wie kann eine Bestellung mehrere Getränke enthalten und somit einen Gesamtpreis?

Mir ist ebenfalls noch eine Frage eingefallen:
Wenn das Programm fertig ist und auf das Tablet übertragen wird und dort auch die Datenbank hinterlegt wird, muss das Tablet auch über Access verfügen, in hinblick auf Treiber bzw. der Möglichkeit, dass das Programm nichts mit der Datenbank dann anfangen kann?

[Asura]

Zitat:

Zitat von jobo (Beitrag 1388665)

Zum Datenmodell noch einige Anmerkungen:

Schlüsselwerte am besten für alle Tabellen über eine zentrale Sequenz erzeugen.


16:
Ich hoffe, es werden nicht 16 Buttons!
Man braucht viele z.B. 27 Buttons für die Buchstaben einer virtuellen Tastatur, 10 für die Ziffern des Nummernblocks usw., aber nicht für verschiedene User. Bitte diese Zahl vergessen - auch wenn sie eine Marke für die "Dimension" des Projekts ist!
In dem Moment, wo man in solchen Kategorien denkt, geht das Design (des Datenmodells oder der GUI/der Logik) leicht in die Hose.

Was ist mit einer zentralen Sequenz gemeint, also diese Aussage verstehe ich nicht.

Bezüglich der 16:
Mir fällt aber keine andere Möglichkeit ein, die eine schnelle Auswahl ermöglicht. Weil ich habe es mir zurzeit so gedacht: Tablet an, Benutzer auswählen (1. Klick), Getränke auswählen (Mind. 1 weiterer Klick) und Kauf bestätigen (3. Klick).
Also, dass der Käufer hier ganz einfach ein Kauf abwickeln kann.

Zur Zeit läuft es über die gute alte Methode: Zettel, Strich unter Getränk und Namen machen und ich darf das dann alles zusammenrechnen, buchen etc. Also: Umständlich für mich, deswegen eine Software.
Jedoch soll sie für den Anwender in Gegensatz zu der Strichliste ebenfalls kein großen Mehraufwand haben, sonst würde die Frage der Käufer aufkommen: Wieso ein neues System, was für mich einen Mehraufwand und Zeit kostet, wenn die Strichliste genauso gut funktioniert. Also eventuell können sie das das nachvollziehen, dass ich hier auch bisschen auf Attraktivität in Hinblick auf Schnelligkeit und "Leichtigkeit" aus bin.

[mkinzler]

Zitat:

Was bedeuten die Attribute mit den eckigen Klammern?

Felder sind nicht unbedingt notwendig.

Für das snowflaking des Datums reicht das Beginndatum (Enddatum = Beginndatum nächste Presiperiode)
Da Guthaben ist auch berechenbar (Problem Redundanz)

Zitat:

Warum existiert bei Tabelle Bestellungen einmal ID und einmal Nr. Ist beides nicht eineindeutig? BestellNr kann doch auch nur einmal in Tabelle Bestellungen vorkommen?

Ich bevorzuge synthetische Schlüssel, BestellNr ist Teil der Nutzdaten.

Zitat:

Es existiert ein Benutzer mit einem Guthaben von +10€. Nun bestellt er über die Software etwas, und es wird ein Eintrag mit der Bestell Nur, Datum, dann der UserID und von nur einem Getränk der Name genommen.
Die Kosten zu dem Datenmodell einer Bestellung kann man ja aus dem Preis des einen Getränks aus der Tabelle Preise beziehen.

Es gilt der jeweilig gültige Preis zum Bestelldatum (aus Tabelle Preise). Bei einer Preisänderung wird ein neuer Eintrag in der Tabelle Preise mit dem Datum der Preisänderung und dem neuen Preis erzeugt.

Zitat:

Deswegen meine Frage: Wie kann eine Bestellung mehrere Getränke enthalten und somit einen Gesamtpreis?

Dann würde ich eine weitere Detailtabelle für die Bestellpositionen verwenden. Gesamtpreis einer Bestellungen dann die Summe der Positionen (berechnet) also jeweils Anzahl * (aktueller) Preis.

was für ein Tablet?

[Asura]

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.

[p80286]

Zitat:

Zitat von Asura (Beitrag 1388688)

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.:gruebel:

Gruß
K-H

[Delphi.Narium]

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.

[jobo]

Zitat:

Zitat von Asura (Beitrag 1388677)

Was ist mit einer zentralen Sequenz gemeint, also diese Aussage verstehe ich nicht.

Bezüglich der 16:
Mir fällt aber keine andere Möglichkeit ein, die eine schnelle Auswahl ermöglicht.

Ein Sequenz ist ein Zahlengenerator, der von sich aus schon eindeutige (idr. einfach aufsteigende) Zahlen ausspukt bei Anfrage. Den (einen) bindet man an die verschiedenen Primärschlüssel, das ist einfach bewährte Praxis. Bei Access geht das vielleicht nicht, hier nimmt man idR ein Autoinc Feld, macht das gleiche, aber je Schlüsselfeld. Ist auch kein Drama.

16: Du kannst einfach eine Dropdownliste/Combobox mit den Usern machen. Der User muss natürlich 2x mehr klicken, aber Du sparst Dir 16 Button und den weiteren Umbau für weitere User.
(mit einem normalerweise üblichen Anmeldevorgang wäre das Thema auch erledigt, Mehraufwand für den Anfang, aber viel sauberer, spätestens wenn die ersten Deine Rechnung anzweifeln)

[Asura]

Zitat:

Zitat von Delphi.Narium (Beitrag 1388709)

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.

[Delphi.Narium]

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 = 'select' then 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.

[Asura]

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 ?

[jobo]

SelAvail, SelText, SelLength ..
bezieht sich evtl auf TSynMemo, nicht auf ein normales/Standard.

[Delphi.Narium]

Zitat:

Zitat von jobo (Beitrag 1388819)

SelAvail, SelText, SelLength ..
bezieht sich evtl auf TSynMemo, nicht auf ein normales/Standard.

Oh :-( Mist, hab' ich nicht dran gedacht, da ich fast nur noch SynEdit nutze.

@Asura
ADOTable ist für die statische Anzeige eines Tabelleninhaltes, ADOQuery für die Ausführung von SQL-Statements.

DataSource benotigt ein TDataSet, ADOQuery und ADOTable sind beide von TDataSet abgeleitet, funktionieren also beide.

Einfach mal von beiden eins aufs Formular pappen, 'ne DataSource dazu und im Objektinspektor zum DataSource bei DataSet schauen, was da so zur Auswahl steht. Alles was da angezeigt wird, kann man auch nutzen.

Bezüglich Deiner Alternative zum SelAvail: Ja, das geht auch so, mit SelText bekommst Du ja den markierten Text. Wie und ob das bei unterschiedlichen Komponenten unterschiedlich funktioniert ist ja eher nachrangig, Hauptsache: Ziel erreicht ;-)

Das Memo ist für die Eingabe von SQLs. Dort tut sich nichts, außer Du gibst dort was ein. Deine Eingabe wird dann an die ADOQuery weitergereicht und nach deren öffnen, mit Hilfe einer DataSource und den dieser zugeordneten Datenkomponente (z. B. einem DBGrid), angezeigt.

Mal einen nicht wirklich sinnvollen Quelltext, mit dem man das demonstrieren könnte:

Delphi-Quellcode:

ADOQuery.Close;
ADOTable.Close;
ADOTable.TableName := 'users';
DataSource.DataSet := ADOQuery;
ADOQuery.SQL.Text := 'select * from users where ID = 1';
ADOQuery.Open;
ShowMessage('Sieht man jetzt den User mit der ID 1?');
ADOQuery.Close;
ADOTable.Open;
ShowMessage('Sieht man jetzt alle User?');
ADOTable.Close;

Dieser Quelltext ist so in etwa für eine Demonstration geeignet, aber nicht für den wirklichen Betrieb.

Wenn ich etwas benötige, um beliebige Daten anzuzeigen, nutze ich nie eine ADOTable, sondern immer nur ADOQuery (bzw. bei anderen Datenbankkomponenten die entsprechenden Gegenstücke). Will ich alle Daten einer Tabelle sehen, dann ist die Abfrage eben Select * from ebendertabelledieichsehenwill.

Ein Hin und Her per Zuweisung von diversen DataSet-Nachkommen zu eine DataSource macht nur den Quelltext verwirrend und scheint mir nicht zielführend.

Mal eben wild zusammengedaddelt so eine Art "Demo" ;-)

Delphi-Quellcode:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, DB, ADODB, ExtCtrls, DBCtrls, Grids, DBGrids, ComCtrls;

type
  Tfrm = class(TForm)
    DataSource: TDataSource;
    ADOQuery: TADOQuery;
    pnTop: TPanel;
    StatusBar: TStatusBar;
    DBGrid: TDBGrid;
    DBNavigator: TDBNavigator;
    Splitter: TSplitter;
    ADOConnection: TADOConnection;
    btnSQL: TButton;
    btnEnde: TButton;
    pnInfo: TPanel;
    SQLEingabe: TMemo;
    Splitter1: TSplitter;
    Tabellen: TMemo;
    procedure btnEndeClick(Sender: TObject);
    procedure btnSQLClick(Sender: TObject);
    procedure TabellenDblClick(Sender: TObject);
    procedure FormCreate(Sender: TObject);
    procedure FormClose(Sender: TObject; var Action: TCloseAction);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  frm: Tfrm;

implementation

{$R *.dfm}

procedure Tfrm.btnEndeClick(Sender: TObject);
begin
  ADOQuery.Close;
  ADOConnection.Close;
  Close;
end;

procedure Tfrm.btnSQLClick(Sender: TObject);
var
  slTables : TStringList;
  slFields : TStringList;
  i        : Integer;
  k        : Integer;
begin
  if not ADOConnection.Connected then begin
    if ADOConnection.ConnectionString = '' then begin
      ADOConnection.ConnectionString := PromptDataSource(handle,'');
    end;
    if ADOConnection.ConnectionString <> '' then begin
      ADOConnection.Open;
      Tabellen.Lines.Clear;
      slTables := TStringList.Create;
      slFields := TStringList.Create;
      ADOConnection.GetTableNames(slTables,false);
      for i := 0 to slTables.Count - 1 do begin
        Tabellen.Lines.Add(slTables[i]);
        ADOConnection.GetFieldNames(slTables[i],slFields);
        for k := 0 to slFields.Count - 1 do begin
          Tabellen.Lines.Add(Format('  %s',[slFields[k]]));
        end;
      end;
      slTables.Free;
      slFields.Free;
    end;
  end;
  if ADOConnection.Connected then begin
    ADOQuery.Close;
    ADOQuery.SQL.Clear;
    if SQLEingabe.SelLength <> 0 then begin
      ADOQuery.SQL.Add(Trim(SQLEingabe.SelText));
    end else begin
      ADOQuery.SQL.Add(Trim(SQLEingabe.Text));
    end;
    if Trim(ADOQuery.SQL.Text) <> '' then begin
      ADOQuery.Open;
    end;
  end;
end;

procedure Tfrm.TabellenDblClick(Sender: TObject);
begin
  if Tabellen.SelText <> '' then begin
    SQLEingabe.SelText := Tabellen.SelText;
  end;
end;

procedure Tfrm.FormCreate(Sender: TObject);
begin
  if FileExists(ChangeFileExt(Application.ExeName,'.sql')) then begin
    SQLEingabe.Lines.LoadFromFile(ChangeFileExt(Application.ExeName,'.sql'));
  end;
end;

procedure Tfrm.FormClose(Sender: TObject; var Action: TCloseAction);
begin
  SQLEingabe.Lines.SaveToFile(ChangeFileExt(Application.ExeName,'.sql'));
end;

end.

Und das Formular dazu:

Delphi-Quellcode:

object frm: Tfrm
  Left = 4
  Top = 4
  Width = 1000
  Height = 640
  Caption = 'Demo-Datenbankoberfläche ;-)'
  Color = clBtnFace
  Font.Charset = DEFAULT_CHARSET
  Font.Color = clWindowText
  Font.Height = -11
  Font.Name = 'MS Sans Serif'
  Font.Style = []
  OldCreateOrder = False
  OnClose = FormClose
  OnCreate = FormCreate
  PixelsPerInch = 96
  TextHeight = 13
  object Splitter: TSplitter
    Left = 0
    Top = 265
    Width = 992
    Height = 8
    Cursor = crVSplit
    Align = alTop
    Beveled = True
  end
  object pnTop: TPanel
    Left = 0
    Top = 0
    Width = 992
    Height = 41
    Align = alTop
    BevelOuter = bvNone
    TabOrder = 0
    object btnSQL: TButton
      Left = 8
      Top = 8
      Width = 97
      Height = 25
      Caption = '&SQL ausführen'
      TabOrder = 0
      OnClick = btnSQLClick
    end
    object btnEnde: TButton
      Left = 112
      Top = 8
      Width = 75
      Height = 25
      Caption = '&Ende'
      TabOrder = 1
      OnClick = btnEndeClick
    end
  end
  object StatusBar: TStatusBar
    Left = 0
    Top = 594
    Width = 992
    Height = 19
    Panels = <>
  end
  object DBGrid: TDBGrid
    Left = 0
    Top = 273
    Width = 992
    Height = 296
    Align = alClient
    DataSource = DataSource
    TabOrder = 2
    TitleFont.Charset = DEFAULT_CHARSET
    TitleFont.Color = clWindowText
    TitleFont.Height = -11
    TitleFont.Name = 'MS Sans Serif'
    TitleFont.Style = []
  end
  object DBNavigator: TDBNavigator
    Left = 0
    Top = 569
    Width = 992
    Height = 25
    DataSource = DataSource
    Align = alBottom
    TabOrder = 3
  end
  object pnInfo: TPanel
    Left = 0
    Top = 41
    Width = 992
    Height = 224
    Align = alTop
    BevelOuter = bvNone
    TabOrder = 4
    object Splitter1: TSplitter
      Left = 697
      Top = 0
      Width = 8
      Height = 224
      Beveled = True
    end
    object SQLEingabe: TMemo
      Left = 0
      Top = 0
      Width = 697
      Height = 224
      Align = alLeft
      TabOrder = 0
    end
    object Tabellen: TMemo
      Left = 705
      Top = 0
      Width = 287
      Height = 224
      Align = alClient
      TabOrder = 1
      OnDblClick = TabellenDblClick
    end
  end
  object DataSource: TDataSource
    DataSet = ADOQuery
    Left = 632
    Top = 48
  end
  object ADOQuery: TADOQuery
    Connection = ADOConnection
    Parameters = <>
    Left = 560
    Top = 48
  end
  object ADOConnection: TADOConnection
    Left = 472
    Top = 48
  end
end

Im realen Leben sollte man allerdings nicht gänzlich auf jedwede Fehlerbehandlung verzichten.

[Asura]

Moin Moin,
nachdem ich erfolgreich nun mein Projekt mit Access beendet habe widme ich mich nun einem neuen Projekt.
Nun möchte ich aber nicht mehr mit Access arbeiten, sondern nun auf eine Datenbank zurückgreifen, die mit einem Server dann gehalten wird.

Ich bin nun auf der Suche nach Anbietern, die günstig Datenbankserver anbieten.
Bis ich einen gefunden habe, würde ich jedoch gerne schon mal beginnen. Welche Lösung wäre die Beste, um direkt eine Schnittstelle zu haben ohne groß im Programmcode was ändern zu müssen.
Eventuell in Richtung Homeserver?
Die Datenbankmodellierung habe ich bereits fertig, wenn man da noch mal rüber schauen könnte und eventuell Verbesserungsvorschläge

[Delphi.Narium]

Mein Vorgehen ist erstmal:

Connectionstring auf die neue Datenbank ändern und Programm starten.
Wenn's nicht geht (was äußerst selten ist) muss ich halt die Probleme beheben.

Wenn man sich bei den SQLs an den Standard hält, sind Probleme eher selten, ab und an werden Datentypen etwas anders gehandhabt, aber die Masse sollte einfach laufen.

[edit - etwas provokant]
Wenn man mit Delphi eine gute Datenbankapplikation geschrieben hat, ist es der egal, gegen welche Datenbank sie läuft, man ändert die Datenbankverbindung (gerne per Dialog) und das Programm läuft gegen eine andere Datenbank. Der Softwareentwickler muss die Datenbanken nicht mal alle kennen.

Klar: Auf Datenbankseite darf man dann nur das nutzen, was alle Datenbanken können. Dafür gibt es den Standard, der weitgehend eingehalten wird.

Befindet sich jedoch die Geschäftslogik (oder auch nur Teile davon) in der Datenbank, kann es schonmal "sportlich" werden.
[/edit]

[TigerLilly]

ad DB-Server:
Wir verwenden den MS SQL Express. Der ist kostenfrei, kann auch im Netz für Mehrbenutzer fungieren + ist mit den großen Editions gut skalierbar. Für uns funktioniert das sehr gut, egal ob Einbenutzer mit Laptop oder Multiuser mit Server.
Ähnliches gibt es auch von Oracle. Alternativ gibt es natürlich auch Firebird, Progress, mySQL.

ad Datenmodell formal:
- die Tabellennamen brauchen die Präfixe nicht. Entscheide dich, wie die Tabellen heißen sollen + aus.
- Die Feldnamen der Tabellen brauchen die Präfixe ebenfalls nicht. Das macht die Namen nur unübersichtlich.
- Die Namensgebung ist nicht einheitlich: bacc_usr_ID und sere_ID - sollte wohl book_sere_ID sein. Ähnliches für booT_ID.
- Die Schreibweise ist nicht einheitlich: Wenn du booT_ schreibst müsste es auch bAcc_ heißen.
- Entscheide dich, ob die nach dem _ groß oder klein weiterschreibst: sere_Name vs catg_name.
- Die Namen der Tabellen sollten entweder alle Einzahl (bevorzugt) oder Mehrzahl sein, nicht mischen (usr_users vs booT_bookingtype).


ad Datenmodell inhaltlich:
- In Zeiten von Password-Hacks würde ich keine Passwörter speichern, sondern nur ihre Hash-Äquivalente.
- Die Verwendung von englischen Bezeichnern bleibt jedem überlassen, ich persönlich finde, dass das kein Muss ist. Verständlichkeit hat Vorrang.
- Ob du mit den angeführten Attributen auskommst, musst du wissen, ich finde die Infos zur Bank und zum User sehr dürftig. Passwörter können ein Ablaufdatum haben, sollten ev. Nicht wiederverwendet werden. USer haben Klarnamen, ev E-Mail etc. Banken vielleicht eine Adresse?
- ob Buchungen wirklich nur eine Kategorie haben, musst auch du wissen, aber ev haben die Kategorien noch eine übergeordnete Kategorie. Bzw gehören zu Ein/Ausgängen.
- Senderreceiver kann ev auch weitere Infos vertragen.

HTH TigerLilly

[p80286]

Warum werden username und pw doppelt abgelegt?
Sollten mehrere User auf einen Bankaccount zugreifen müssen/können, sollte diese Relation über eine entsprechende Tabelle abgebildet werden.

Gruß
K-H

@Delphi.Natrium
Ganz so einfach ist es in der Praxis nicht, aber das Prinzip ist schon korrekt.

[jobo]

Zitat:

Zitat von Delphi.Narium (Beitrag 1390840)

Befindet sich jedoch die Geschäftslogik (oder auch nur Teile davon) in der Datenbank, kann es schonmal "sportlich" werden.

"Sportlich" wird es m.E. vor allem dann, wenn Teile der Geschäftslogik irgendwo liegen.
Die Geschäftslogik sollte ein Ganzes sein und nicht irgendwo verstreut. Ein Server ist ein Server ist ein Server usw.
Eine Entschuldigung für die Aufteilung von Geschäftslogik ist allenfalls, wenn diese Aufteilung kongruent zu den Logikbereichen ist, die der jeweilige Teil bedient. Also 2 Server, 2 Zuständigkeitsbereiche usw.
Wir haben eine Anwendung, die die gesamte Geschäftslogik in der Datenbank hält. Sehr unsportlich. Nein, Spaß. Eignet sich super für heterogene Clientlandschaften inkl. verschiedener Webserver Anbindungen. Alles nur noch "dumme" Clients, also etwas netter formuliert reine Visualsierung.

[Delphi.Narium]

Zitat:

Zitat von jobo (Beitrag 1390855)

Zitat:

Zitat von Delphi.Narium (Beitrag 1390840)

Befindet sich jedoch die Geschäftslogik (oder auch nur Teile davon) in der Datenbank, kann es schonmal "sportlich" werden.

"Sportlich" wird es m.E. vor allem dann, wenn Teile der Geschäftslogik irgendwo liegen.
Die Geschäftslogik sollte ein Ganzes sein und nicht irgendwo verstreut. Ein Server ist ein Server ist ein Server usw.
Eine Entschuldigung für die Aufteilung von Geschäftslogik ist allenfalls, wenn diese Aufteilung kongruent zu den Logikbereichen ist, die der jeweilige Teil bedient. Also 2 Server, 2 Zuständigkeitsbereiche usw.
Wir haben eine Anwendung, die die gesamte Geschäftslogik in der Datenbank hält. Sehr unsportlich. Nein, Spaß. Eignet sich super für heterogene Clientlandschaften inkl. verschiedener Webserver Anbindungen. Alles nur noch "dumme" Clients, also etwas netter formuliert reine Visualsierung.

@Jobo:

Du beschreibst eigentlich genau das, was ich meine:
entweder <-> oder.

Logik in der Datenbank: Es ist egal, was für ein Client genutzt wird. Die Logik zieht immer.
Heißt aber auch: Immer die gleiche Datenbank und nicht bei einem Kunden diese und beim nächsten Kunden jene und dann könnten wir auch noch "sonne oder solche" Datenbanken nehmen ...
Übertrieben formuliert. Logik in der Datenbank: andere Datenbank -> neue Implementierung.

Die Logik liegt in der Applikation: Dann nur diese Applikation und sonst niemand.

Ein bisserl Logik in der Datenbank und die "Reste" in N Applikationen? NoGo

Wer sowas entwirft, empfiehlt ... gehört gehauen ;-)

[Asura]

Bezüglich Datenbank Allgemein:

Dann liegt das noch an einem Grundverständnis bei mir:
Ich bin bei der Variante mit Access über die Komponente ADOQuery gegangen, wenn ich nun ein anderes System nutze, wie zum Beispiel SQL Express, oder Firebird oder MySQL, dann würde sich das doch ändern? Aber dann genügt es doch nicht mehr einfach nur den "ConnectionString" bzw. die Adressierung der Datenbank zu ändern, sondern ich müsste komplett die Komponente wechseln und somit sehr viel im Programmcode ändern?


Dann Dankeschön für die kritische Bewertung!
Ich werde davon wohl so gut wie alles umsetzen.

Bezüglich der Hash-Ablage und warum ich zwei Passwörter verwende.
Das eine ist das Passwort für das Programm zum einloggen, dass andere sind die Benutzerdaten für den Bankaccount.
Mein Vorhaben sieht so aus, dass das Programm sich in den Bankaccount des jeweilen Users nach der Auswahl seiner Bank einloggt, die Umsätze herunterlädt und den Benutzer dann die Wahl der Kategorievergabe oblässt und dann diese statistisch darstellt und bewertet.
Deswegen kann ein User (Client) mehrere Bankaccounts haben.

Wegen der Passwortablage:
Ich bin mir nicht sicher, ob du das meinst was ich vorhabe:
Ich würde das Passwort über das Programm verschlüsseln und der verschlüsselte Inhalt wird dann auf die Datenbank abgelegt. Wenn man sich einloggt, entschlüsselt er den Wert und gleicht diesen dann ab.
Ich wollte auch eine Option des automatischen Logins einspeisen, habe das zurzeit zwar noch alles ohne Verschlüsselung aber er speichert die Logindaten in einer Ini-Datei ab. Hier würde ich dann auch das Passwort verschlüsseln und nur diesen Wert in die Ini schreiben und diesen wieder laden, entschlüsseln, vergleichen.

Möchte noch kurz anmerken: Das Programm zielt nicht ab kommerziell genutzt zu werden. Das wird nur unter ausgewählten Personen verteilt. Ich habe leider gar keine Rechte mit einer Student Version von RAD hier kommerziell zu werden. Also würde davon nur hauptsächlich Ich und ein paar gute Bekannte davon profitieren.


//EDIT:

Ich habe nun die Datenbankmodellierung angepasst.
Ich habe bei Senderreceiver ein "Usage" hinzugefügt, der soll dann ein Boolean Wert haben (Sender = 0, Receiver = 1).
Bei Bookings ist Bookingtype nun raus und soll nun die Oberkategorie (Einzahlung/Auszahlung) sein. Hier habe ich eine Frage. Da es ja nur die zwei Optionen gibt, würde es nicht reichen einfach nur eine Spalte bei Kategorien hinzuzufügen als Boolean mit 0 = Eingang, 1 = Ausgang. Aber es stimmt, dass dies eher eig. als Oberkategorie dienen soll. Also so wie ich das jetzt habe nur eventuell in der Tabelle Bookingtype statt Name den Boolean wert?
Man müsste dann später ja nur über die Kategorien gehen, um die Eingänge bzw. die Ausgänge darzustellen.

[Delphi.Narium]

Zitat:

Zitat von Asura (Beitrag 1390926)

Bezüglich Datenbank Allgemein:

Dann liegt das noch an einem Grundverständnis bei mir:
Ich bin bei der Variante mit Access über die Komponente ADOQuery gegangen, wenn ich nun ein anderes System nutze, wie zum Beispiel SQL Express, oder Firebird oder MySQL, dann würde sich das doch ändern? Aber dann genügt es doch nicht mehr einfach nur den "ConnectionString" bzw. die Adressierung der Datenbank zu ändern, sondern ich müsste komplett die Komponente wechseln und somit sehr viel im Programmcode ändern?

Doch genau das: Andere Datenbank, anderer Connectionstring und gut ist es.

Es wäre für meine Begriffe recht erbärmlich von Delphi, wenn ich je Datenbank andere Datenbankkomponenten nutzen müsste.

Habe im Laufe meines Lebens so einiges an Software schreiben müssen, bei dem ich zu Beginn der Entwicklung noch nicht wusste, gegen welches DBMS sie denn letztendlich laufen wird.

Das wäre ja mörderisch, wenn man dann die Software erstmal gegen die zur Entwicklung verfügbare Datenbank mit den passenden Komponenten entwickelt und wenn man dann irgendwann erfährt, dass beim Kunden eine andere Datenbank zum Einsatz kommt, macht man alles, mit anderen Datenbankkomponenten, neu?
Oder die Software kommt bei mehreren Kunden zum Einsatz, aber jeder hat sich für ein anderes DBMS entschieden? Dann gibt es entsprechend viele Varianten der Software, schön mit jeweils eigenen Komponenten?

Und was ist, wenn aus irgendeinem Grund mal die zuerst gewählte Datenbank wegfällt? Eine Neuentwicklung mit anderen Datenbankkomponenten?

Warum mag man wohl bei den ADO-Komponenten bei der Erstellung des Connectionstrings eine recht große Auswahl an unterschiedlichen Möglichkeiten zur Erstellung des Connectionstrings und eine (ggfls. systemabhängig) mehr oder weniger große Auswahl an unterschiedlichen DBMS bekommen? Nur um dann festzustellen, dass es nur gegen Access funktioniert?
In dem Fall würd' für meine Begriffe die sofortige Deinstallation dieser Komponenten das Einzige sein, was ich mit ihnen mache!

Es gibt diverse Möglichkeiten, um auf Datenbanken zuzugreifen, sei es FireDac, UniDac, dbgo, ADO, Zeos, (manche kennen noch die BDE ;-)) und was weiß der Geier sonst noch.
Sicherlich sollte man am Anfang eine Entscheidung treffen, welche Variante man nutzt.
Aber egal welche man nutzt: Sobald man die Datenbank wechselt, muss man auch die Datenbankkomponeten wechseln?
Das hieße doch letztlich: Für jede Datenbank müsste es eine eigene Palette von entsprechenden Datenbankkomponenten geben. Das wäre ja dann fast schon absurd.
Wo blieben denn da die datenbankunabhängige Entwicklung von Datenbanksoftware?

Brauchen wir dann eventuell für jede Sprache ein eigenes TEdit, ein eigenes TMemo ...

Delphi ist hervorragend dazu geeignet, Datenbanksoftware zu schreiben und ist dabei nicht auf eine bestimmte Datenbank festgelegt. Dies kann nur gelingen, wenn es eben nicht erforderlich ist, beim Datenbankwechsel die gesamte Datenbankschnittstelle auszutauschen.

Probleme beim Datenbankwechsel kann es geben, wenn sehr datenbankspezifische SQLs genutzt werden. Die eine DB will halt top 10, die andere first 10, eine andere RowNum < 11, wieder eine andere Limit 10 und das auch noch an unterschiedlichen Stellen des SQLs, nur um an die ersten 10 Zeilen einer Ergebnismenge zu kommen. Das ist aber bei allen Datenbankkomponenten gleich.

Wenn Du mit dem Auto normalerweise über die Autobahn zur Uni/Arbeit/Oma/... fährst und nicht über die Landstraße, wirst Du doch nicht dann, wenn Du ausnahmsweise mal über die Landstraße fährst, vorher einen entsprechenden Motor einbauen? (ja, der Vergleich hinkt.)

Probleme beim Wechsel der Datenbank kann und wird es geben, aber nicht aufgrund der Komponenten, sondern Aufgrund der Unterschiedlichen Syntax im SQL, sobald man auch nur um Haaresbreite vom (weitgehend einheitlich unterstützten) SQL-Standard abweicht.

Man muss sich im realen Leben also Gedanken darüber machen, welche Änderungen am SQL notwendig sind, um mit unterschiedlichen Datenbanken zusammenarbeiten zu können. Und darüber, wie man das im Programm am besten gehändelt bekommt. Hierzu gibt es im Forum schon vielfältige, teils recht kontroverse, Diskussionen. Die solltest Du mal zu Rate ziehen.

ADO ist jetzt vielleicht nicht aus jedermanns Sicht die beste Datenbankschnittstelle, aber welche Datenbank man damit nutzt, sollte egal sein.

Mein konkretes Vorgehen in Deinem Fall wäre:

Connectionstring auf die neue Datenbank ändern, in der neuen Datenbank für das Vorhandensein des benötigten Datenmodells sorgen.
Programm starten und auf Herz und Nieren testen.
Und nur wenn Probleme auftreten nach einer Möglichkeit der Beseitigung suchen und diese (wenn irgend möglich) so wählen, dass das(die) bisher unterstützte(n) DBMS auch weiterhin genutzt werden kann(können). (Unterschiedliche Lösungsansätze findet man hier im Forum.)