Welches DBMS sollte ich nehmen?

[Marco Steinebach]

Hallo,
Ich hätte, bevor ich weiter wie wild ausprobiere, noch zwei Fragen:
@Rolf: und ElevateDB bringt, sozusagen, seinen eigenen Server gleich mit?
@Delphi.Narium: blöde Anfängerfrage, jedenfalls was Datenbanken angeht , die ADO-Komponenten sind...?

Ganz herzlich grüßt
Marco

[haentschman]

Moin...

Zitat:

ElevateDB bringt, sozusagen, seinen eigenen Server gleich mit?

"The ElevateDB Server is a small single executable, only requires a single INI text file for configuration, and can be run as an application or Windows service."
Der Server muß imho auch gestartet werden. Die Datenbank ist ein File pro Tabelle...wie Paradox.

Zitat:

die ADO-Komponenten sind

Sind Zugriffskomponenten wie ZEOS, IBDAC etc. Nur das ADO seine Eigenheiten hat. Syntax die vom Standard abweicht...etc. Viele sind von ADO u.a. deswegen weg.
https://www.google.de/search?q=delph...w=1876&bih=990

[mkinzler]

Ado ist der Nachfolger von ODBC und der Vorgänger von ODBC ()

[Delphi.Narium]

Zitat von haentschman:

Zitat:

die ADO-Komponenten sind

Sind Zugriffskomponenten wie ZEOS, IBDAC etc. Nur das ADO seine Eigenheiten hat. Syntax die vom Standard abweicht...etc. Viele sind von ADO u.a. deswegen weg.

Bei Delphi 7 hat man standardmäßig Datenbankkomponenten für die BDE (TTable, TQuery ...) und die ADO-Komponenten (TAdoConnecntion, TAdoQuery, TADoTable, ...) für die ADO-Schnittstelle.

Das ADO eine eigene Syntax hat, die vom Standard abweicht, wäre mir allerdings neu. Nutze sie seit mehr als 20 Jahren und mir ist noch nichts derartiges aufgefallen.

Die SQL-Syntax ist immer von der Datenbank abhängig. Bei Oracle braucht man die Oracle-Syntax, bei PostGres die PostGres-Syntax, bei FireBird die FireBird-Syntax und bei Access die Access-Syntax. Und genau hier kommt der Irrglaube her, da für viele ADO = Access ist und das ist schlicht und einfach falsch.

Egal ob ich nun per Zeos oder ADO auf 'ne FireBird-Datenbank zugreife: Die Syntax ist immer gleich, die SQLs kann ich 1:1 übernehmen.

Und nein: Die ADO-Schnittstelle sit nicht zwingend die Beste, aber sie ist für normale Anwendungen ausreichend gut und ausreichend verlässlich. Zumindest sind mir bisher keine Probleme beim Datenbankzugriff (egal auf welche DB) aufgefallen, die auf die ADO-Schnittstelle zurückzuführen wären.

Und ich schrieb genau deshalb:

Zitat:

Wenn alle Stricke reißen:

Also mögliche Lösung für den Fall, dass keine andere Lösung gefunden werden kann.

Die Zeos-Komponenten nutzen direkt die fbclient.dll von FireBird.

Bei der Verwendung der ADO-Schnittstelle nutzt man zuerst diese, die dann den ODBC-Treiber von Firebird nutzt, der dann mit Hilfe der fbclient.dll von FireBird auf die Datenbank zugreift. Man hat halt ein paar Schnittstellen mehr dazwischen, was für den Programmierer in Delphi absolut transparent ist.

In allen Fällen pappt man die Komponenten für die Datenbankschnittstelle auf's Formular (...) und arbeitet mit der Datenbank.

[haentschman]

Zitat:

Das ADO eine eigene Syntax hat, die vom Standard abweicht

Nicht SQL Syntax...

Delphi-Quellcode:

Qry.Parameters.ParamByName('Wert').Value 
// statt
Qry.ParamByName('Wert').AsString

...imho geht bei ADO nur ".Value"

[Delphi.Narium]

Zitat von haentschman:

Zitat:

Das ADO eine eigene Syntax hat, die vom Standard abweicht

Nicht SQL Syntax...

Delphi-Quellcode:

Qry.Parameters.ParamByName('Wert').Value 
// statt
Qry.ParamByName('Wert').AsString

...imho geht bei ADO nur ".Value"

Die Delphi-Syntax bei ADO mag anders sein als bei Zeos, BDE, UniDac, FireDac, ADO .... Aber das als Argument für "Sollte man nicht nehmen", halte ich für gewagt. Mir ist nicht bekannt, dass man ohne Änderungen am Quelltext Datenbankschnittstellen untereinander austauschen kann (egal welche gegen welche).

Anpassungen braucht man immer, das könnte man also bei alten Programmen, in denen man z. B. die BDE durch "beliebige Datenbankschnittstelle" ersetzen möchte, bei jeder anderen Komponente sagen. Sie weichen alle irgendwie ab und haben (in Teilbereichen) eine andere Syntax.

Und dass ADO nur .Value kennt, ist einfach nur falsch.

Bei mir kennen die Komponenten zumindest

Delphi-Quellcode:

  ADOQuery1.FieldByName('').AsBCD;
  ADOQuery1.FieldByName('').AsBoolean;
  ADOQuery1.FieldByName('').AsCurrency;
  ADOQuery1.FieldByName('').AsDateTime;
  ADOQuery1.FieldByName('').AsSQLTimeStamp;
  ADOQuery1.FieldByName('').AsFloat;
  ADOQuery1.FieldByName('').AsInteger;
  ADOQuery1.FieldByName('').AsString;
  ADOQuery1.FieldByName('').AsVariant;
  ADOQuery1.FieldByName('').Text;
  ADOQuery1.FieldByName('').OldValue;
  ADOQuery1.FieldByName('').NewValue;
  ADOQuery1.FieldByName('').Value;

(Die hab' ich auch schon (soweit ich mich erinnere) in Delphi 4 genutzt.
Und da wir hier von Delphi 5 reden, liegt (vermutlich) mein olles Delphi 7 näher dran, als eine aktuelle Delphiversion.

[haentschman]

Zitat:

Und dass ADO nur .Value kennt, ist einfach nur falsch

...bei Parametern!

Warum fühlst du dich angriffen?

[Marco Steinebach]

Hallo zusammen,
Uiii, ich bin ganz erstaunt, das mein gutes, altes D5 mal was hat, was man nicht nachinstallieren muss.
Da die ADO's schon drin sind, mach ich mich jetzt mal dran und sage herzlichen Dank für euer Feedback!

Herzlichen Gruß
Marco

[Marco Steinebach]

Hallo nochmal,
Kann mir mal jemand von den FireBird-Experten helfen, bitte:
FireBird-Server ist auf einem Windows-Rechner installiert.
WIN10, 64-bit
FB-Server: 3.0.7, 32-bit
Hab ihn mittels der .exe installiert, um hier mal irgendwas ans Laufen zu kriegen.
Prozess taucht im TaskManager auf.

Auf meinem Arbeitsrechner:
ODBC für FireBird 2.5.... (32-bit) installiert, alles angehakt, dass er auch die GDS32.dll erstellt.
Unter Systemsteuerung | Verwaltung | ODBC Datasource (32-bit)
neue Datenquelle mit Firebird-Treiber hinzugefügt.
Was, um himmelswillen, muss ich jetzt bei Datenbank angeben, und, muss es die vorher geben, oder wird die angelegt.
Ich habe mal, testhalber
192.168.2.2:examples\empbuild\employee.fdb
angegeben,
Username: SYSDBA
Pw: masterkey
Rest ist leer - und Verbindung geht nicht, weil:
"unable to establish connection".
Häää? Hiiiilfe!

Herzlich grüßt
Marco

[jsheyer]

Das Problem ist, das Verbindung/Security seit 3.0 geändert hat, du hast jetzt einen Firebird Server 3.x aber den ODBC Treiber 2.x installiert, das funktioniert nicht.
Der ODBC Treiber für Firebird 2.5 kann mit der neuen Security Technik nicht umgehen.
Da es soweit ich weiß, keinen ODBC Treiber für die 3.0 Version gibt, zumindestens sehe ich keinen, am besten den Firebird 2.5.x Server installieren.