Wie und womit realisiere ich am besten den Zugriff auf verschiedene SQL-Server???

[Axel Baruschke]

Hallo Leute,

das Forum hier hatte mir schon prima geholfen beim Umstieg von Paradox auf eine echte Client/Server Datenbank Interbase. Danke dafür!

Nun bekomme ich immer mehr Anfragen, ob mein Programm auch mit Oracle, MS-SQL Server etc. läuft. Viele wollen nicht noch zusätzlich einen Interbase-Server installieren und administrieren.

Womit realisiert man am besten die Zugriffe auf unterschiedliche SQL-Server? Derzeit nutze ich Interbase und IBX. Sollte man die BDE, ODBC oder Direkt-Zugriffe nutzen?
Gibt es für Testzwecke eine Art Oracle-SQL Server "light"?
Es sollte so sein, das ich die Anwendung habe und die Datenbankzugriffe in eine Datenschicht lege, die austauschbar sein soll. Dazu habe ich bei meinen SQL Statements schon möglichst auf Standards gesetzt.

Worauf sollte man da achten? Wie könnte man an die Realisierung am besten ran gehen?

Danke für jeden Hinweis/Tipp.

Gruß
Axel Baruschke

[Matthias Fichte]

Hallo Axel,
Soweit ich weiss, gibt es bei Oracle ein kostenloses Paket<BR>
fuer Entwickler. Schau do bei Oracle mal nach.<BR>
Gruss<BR>
Matthia

[Heiko Luettge]

Hallo Axel, <br>
in diesem Fall würde ich ADO empfehlen,<br>
dummerweise gibt es für Interbase noch immer keinen richtigen Treiber dafür.<br>
Das Auslagern in eine Dll kann ich nicht empfehlen (hoher Verwaltungsaufwand).<P>
Sinnvoll wäre die Nutzung von OOP, also eine Basisklasse TAxelsQuery , <br>von der du eigene Queries ableitest TAxelsIBQuery, TAxelsOracleQuery.<br>
Klingt aufwendig, ist es auch.<P>
Ich sage meinen Kunden, das Interbase nicht administriert werden muß,<br>
das muss reichen
<P>
Heiko<p>
ps: unter http://otn.oracle.com/software/content.html kannst du dir die personal edition der 8i oder 9i laden (etwas 1,5 gig .,

[Bernhard Geyer]

Hallo heiko,
ich würde eine generelle Umstellung auf ADO nicht empfehlen, da z.B. Oracle nicht alle Möglichkeiten über ADO bereitstellt oder es für andere Datenbanken keine oder nur schlechte Implementierungen gibt. So hatte ich z.B. über ADO Probleme mit bestimmte Arten von parametrisierten Abfragen. Und da eh sich viel schon auf ADO.NET konzentriert wird in dem Bereich auch keine großartige Weiterentwicklung betrieben.

Hallo Axel
Am sinnvollsten ist es meiner Meinung nach für alle Datenbanken eine möglichst nativen Zugriff zu realisieren (z.B. ADO für MS-SQL, Oracle Net-Client, MySQL über libmysql.dll, Interbase über IBX). Um eine Abstraktion der Unterschiede der verschiedenen Datenbanken solltest Du auf das Bridge-Pattern / Brücken-Muster setzen (Ein Entwurfsmuster, welches deine Austauschbarkeit der DB-Schicht realisiert).

Für den nativen Zugriff gibt es z.B. folgende Komponenten:
- http://www.sqldirect-soft.com/<br>
- http://www.microolap.com/products/dac/dacproducts.htm (Verwenden wir selbst für MySQL

[Gerd Paulus]

Hallo Axel,

helfen kann ich dir leider nicht, aber stehe vor demselben Problem. Die Grenze von Paradox ist nahe und ich plane den Umstieg. Nur den Weg sehe ich noch nicht. Derzeit greife ich über TTable und BDE auf Paradox zu.

Wie hast du den Umstieg auf Interbase vollzogen?<BR> Hast du alles auf TQuery umgestellt?<BR>Bei Einzeltests war bisher immer Paradox schneller als Interbase, allerdings lagen dabei die Daten lokal, in Echtzeit liegen sie aber auf dem Netz. Dort habe ich bisher aber keinen Interbase-Server eingerichtet. (Datenbankgröße 300MB, 150Tabellen, größte Tabelle 55MB, bis zu 20 User gleichzeitig)<BR>Benötigt man für Interbase die Delphi C/S-Version?<BR>Wo lagen die größten Probleme?

Für deine Tips wäre ich dankbar.

Gruß
Ger

[Enrico Schubert]

Hallo Leute,

wollte eben dieselbe Diskussion eröffnen. Ich stehe vor dem selben Problem, eine Applikation zu schreiben, die man auf verschiedene Datenbanken aufsetzen kann. Derzeit arbeite ich noch mit Delphi5 (Ent.). Jetzt hab ich mir mal die Funktionsmatrix von Delphi7 angeschaut. Da ist ja das dbExpress aufgeführt, das auch Zugriffe auf verschieden Datenbanken erlaubt. Kann ich mit diesen Treibern das Problem lösen oder binde ich mich damit bei der Entwicklung an eine bestimmte DB?
Weiterhin hatte ich ja an ADO gedacht. Das wurde aber weiter oben als nicht so optimal eingestuft. Hat da vielleicht schon jemand mit dbGo (das ist doch ADO unter Delphi 7 oder?) Erfahrungen gesammelt?
Würde mich (und bestimmt auch viele andere) sehr freuen, wenn Leute, die mit diesen Sachen schon Erfahrung haben, hier mal ein paar kurze Tipps abgeben könnten.

cu Enric

[Andreas Kosch]

Hallo,

dieses Problem ist uralt - und in den ganzen Jahren hat sich gezeigt, dass es keine universell passende Implementierung gibt. Man muss sich in jedem Fall für das kleinere Übel entscheiden:

Plan A: Die Anwendung folgt dem Prinzip des "Kleinsten gemeinsamen Nenners" und verzichtet auf jedes Feature, dass Datenbankspezifisch ist. Wenn der Zugriffsweg auch für alle benötigten Datenbanken offen steht, kann man alles in einen gemeinsam genutzten Sourcecode packen.

Plan B: Die Anwendung nutzt die Features der einzelnen Datenbanken konsequent aus und greift je Datenbank auch auf den am Besten geeigneten Zugriffsweg zurück. Dies hat allerdings zur Folge, dass es je Datenbank einen eigenen spezifischen Sourcecode gibt, der als Verbindungsglied zu den gemeinsamt genutzten Programmteilen dient.

Die "älteren" Zugriffswege BDE, ADO und dbExpress versuchen den Plan A umzusetzen, wobei die "neueren" Zugriffswege (ADO.NET) zu Plan B umschwenken, da nur so der Anwender in den Genuß der bezahlten SQL Server-Fähigkeiten kommt :-)<br>
(die Leistungs- und Funktions-Unterschiede der verschiedenen SQL-Server werden trotz SQL-Standard auch zukünftig eher zu- als abnehmen, so dass sich dieses Problem weiter verschärfen wird)

Letztendlich entscheidet jedoch die Qualität der Datenbanktreiber über Erfolg und Mißerfolg - und bei diesem Kriterium hat ADO die Nase gegenüber dbExpress (und den SQLLinks der BDE) vorn, da die OLE DB-Provider deutlich Bugfreier sind als die handvoll verfügbaren dbExpress-Treiber (DB2, Interbase, MySQL, Oracle, Informix, MSSQL).
&#10

[Agustin Angeles]

Hallo Axel, hallo Enrico,

ich habe mich auch mit dieser Problematik beschäftigt, ich empfehle euch folgende Seite:

http://www.techinsite.com.au

mfG

Agustin Angele

[Dr.med.Bernhard Schwabe]

hi

ich schließe mich den Ausführungen von Andreas Kosch voll an und möchte hinzufügen: Sofern man konsequent ein Fat-Server-Prinzip verfolgt, werden die Client-seitigen SQL-Statements auf simple Grundstatements zusammenschnurren, die auf allen Systemen ablaufen. Es muss "nur" der Server in Triggern und Stored Procedures voll ausgereizt werden. Die Crux liegt bei einem solchen Vorhaben natürlich in der genauen Kenntnis der spezifischen Server-Features und man muss nun ehrlicherweise sagen, dass z.B. ein MSQL-Server eine andere Gewichtsklasse (in jeder Hinsicht) als Interbase ist. (Ich bin erklärter Fan von beiden)

Wenn ich an Eurer Stelle wäre, würde ich auf jeden Fall Plan B verfolgen, und mich nacheinander an die verschiedenen Systeme heranwagen. Läuft ein Programm oder eine Komponente perfekt unter Interbase und oder MSQL, habt Ihr schon viele Freunde! Der Witz liegt nicht im kleinsten gemeinsamen Nenner, sondern im Ausreizen des spezifischen Systems, was letztlich dann doch zu unterschiedlichen Programmen/Leistungen führt.

Gruß
Bernhar

[Christian Hass]

ich habe das Problem folgendermaßen gelöst:
<pre>
TMyQuery = class(TComponent)
private
FConnected: Boolean;
FConnectionType: TDBType;
FSQL: TStrings;
FBDEConnection: TDatabase;
FBDEQuery: TQuery;
FMySQLConnection: TSQLConnection;
FMySQLQuery: TSQLQuery;
FDataSource: TDataSource;
public
constructor Create(AOwner: TComponent); override;
destructor Destroy; override;
function ConnectToDatabase(DBType: TDBType; UserName, Pass, Server, DBName: String): Integer;
function Open: Boolean; // returns true in case of the SQL query returns results
procedure ExecSQL;
procedure Close;
procedure Disconnect;
protected
procedure SetSQL(const Value: TStrings);
published
property SQL: TStrings read FSQL write SetSQL;
property Conected: Boolean read FCOnnected;
property ConnectionType: TDBType read FConnectionType;
property DataSource: TDataSource read FDataSource;
end;
</pre>
Diese Klasse MyQuery stellt einfach alle benötigten Funktionen nach außen zur Verfügung. Damit kann man recht gut arbeiten. Und als Datenbanken kann ich nun Paradox (=Dateibasiert), MySQL-Server und ODBC Schnittstellen angeben. Wenn man die Klasse weiter ausbaut, könnte man damit auch andere Verbindungen managen. Eine recht Komfortable Möglichkeit, find ich..

[HORATIO]

Hallo Christian,
das wäre auch die Lösung meiner Vorstellung, alte Applikationen aufzupeppen, die schon komplett auf TQuery basieren.
Eine eigenen TQuery (mit fieldbyname-zugriff , recordcount usw.)
zu erzeugen aus Daten, die man dahinter beliebig selbst besorgen kann. Nach oben aber wie eine TQuery sein. Kannst Du das Innenleben Deiner Klasse zeigen? Am Beispiel könnte ich dann weiterkommen.
Wolfgang Dümche

[Christian Hass]

Hallo Wolfgang,
klar kann ich dir meine Unit dafür geben. Lade sie dir am besten von meinem Server. Wenn der Link mal nicht geht, dann einfach später erneut versuchen. DSL Leitung!

<a href="http://www.dalord.yi.org/software/MyDBAcc.pas">MyDBAcc.pas</a>

Die Unit ist noch nicht optimal... also von der Code-Optimiertung und Fehlerbehandlung etc. her. Habe sie damals geschrieben um zu testen ob es so überhaupt ohne Probleme geht. Und es geht! Habe sie aber seit dem nicht weiter optimiert, sondern nur ein wenig angepasst. arbeite selber grad noch daran; aber sie funktioniert so schon ohne Probleme. Wenn du sie erweiterst, kannst du mir ja eine Version von dir zukommen lassen (<a href="mailto:[email protected]">[email protected]</a>).

Grüsse aus München,

Chri