TADOTable, TableDirect, SQL in TableName, SQL Server

[edwpi]

Hallo,

ich hab folgendes Problem:
Die Software, die ich seit kurzem betreue, soll auf den Sql Server umgestellt werden. Die Applikation ist mit Delphi 6 entwickelt worden. Im Quellcode wird an sehr vielen Stellen TADOTable in Verbindung mit TableDirect := True verwendet. Nun unterstützt der Sql Server kein cmdTableDirect. Was das ganze nun noch schlimmer macht ist, dass noch dazu SQL-Stmts im TableName eingetragen sind.
Bsp:

Delphi-Quellcode:

  t := TADOTable.Create(nil);
  t.ConnectionString := <<ConnectionString>>
  t.TableDirect := True;
  t.TableName := 'SELECT col1, col2 FROM tab';
  t.Open;

Für die derzeitigen Datenbanken (MS Access und Sqlbase) funktioniert dies einwandfrei, jedoch konnte ich dieses Beispiel nicht auf den Sql Server übertragen. Der Sql Server unterstützt cmdTableDirect nicht und lässt im TableName kein Sql-Stmt zu (ist dies korrekt?).
Jetzt besteht mein Problem darin, dass der gesamte Quellcode mit solchen Konstrukten übersät ist. Wie kann ich (möglichst einfach, mit wenig Aufwand) die Umstellung machen (wenn möglich auch so, dass die anderen Datenbanken weiterhin unterstützt werden)?

Meine erste Idee wäre eine Subklasse von TADOTable zu erstellen, welche im Hintergrund eine TADOQuery verwendet. Jedoch hab ich mich bisher nur sehr wenig mit ADO beschäftigt und kann die Schwierigkeiten kaum abschätzen. Es stellt sich schließlich auch die Frage, ob dies überhaupt möglich ist und zu einer Lösung führt?

Ich wäre sehr dankbar, wenn mich jemand beraten könnte. Danke

[hoika]

Hallo,

du könntest Views benutzen.

Create View_1 as
SELECT col1, col2 FROM tab

Per $IFDEF steh dann

Delphi-Quellcode:

{$IFDEF SQL_SERVER}
t.TableDirect := False;
t.TableName := 'View_1'; 
{$ELSE}
t.TableDirect := True;
t.TableName := 'SELECT col1, col2 FROM tab'; 
{$ENDIF}

Nicht schön, geht aber

Weil das so blöd aussieht,
würde ich das eher so machen

Einmalig

Delphi-Quellcode:

{$IFDEF SQL_SERVER}
const C_TableDirect = False;
{$ELSE}
const C_TableDirect = True;
{$ENDIF}

"Tabellen"-Namen

Delphi-Quellcode:

{$IFDEF SQL_SERVER}
const C_ViewX = 'View_1';
{$ELSE}
const C_ViewX = 'SELECT col1, col2 FROM tab';
{$ENDIF}

Und im Code sieht es dann so aus.

Delphi-Quellcode:

t.TableDirect := C_TableDirect;
t.TableName := C_ViewX;

Du musst per Grep nur alle TableDirect-Zeilen suchen
und entsprechend anpassen.

Dass der SQL-Server andere SQL-Statements hat,
ist mir auch klar. Aber es wäre ein Anfang.
Die Korrektheit der Statements kannst du nur durch Testen
(idealerweise Unit-Test) prüfen.

Dadurch, dass du eh jede Stelle ändern musst,
kannst du es dann auch gleich nach dem Ändern testen.


Heiko

[nahpets]

Hallo,

Zitat von edwpi:

Delphi-Quellcode:

t := TADOTable.Create(nil);
t.ConnectionString := <<ConnectionString>>
t.TableDirect := True;
t.TableName := 'SELECT col1, col2 FROM tab';
t.Open;

wenn es immer exakt so im Quelltext ist, dann sollte die Änderung durch globales Suchen und Ersetzen möglich sein:
Du brauchst dazu drei Schritte:

1. ersetze TADOTable durch TADOQuery.
2. ersetze t.TableDirect := True; durch // t.TableDirect := True; (hier könntest Du auch durch einen leeren String ersetzen).
3. ersetze t.TableName := durch t.SQL.Text := .

Danach sollte ein Kompilieren wieder möglich sein, sofern Du keine weiteren TAdoTable-spezifischen Attribute und/oder Methoden genutzt hast. Die Benutzung von FieldByName ... ist bei TAdoQuery und TADoTable identisch.
Ob alle SQL's mit dem SQL-Server in unveränderter Form laufen, muss Du ausprobieren.

[hoika]

Hallo,

dadurch wird aber auch der Code für Access / SQLBase mit verändert.
Der Code soll ja für mehrere DB's funktionieren.

Inwiefern das Ersetzen der TTable durch TQuery bei einer Access-DB
sich auswirkt, sollte man prüfen,
und zwar mit einer gut gefüllten DB
(Stichwort Performance)


Heiko

[nahpets]

Hallo,

klar wird dadurch der gesamte Code für alle Datenbanken verändert. Es dürfte aber sinnvoller sein, einen Code für alle Datenbanken zu verwenden, als für jede Datenbank eine "Extrawurst" zu braten. Mit TAdoQuery und Access hatte ich bisher keine Probleme.

Selbstverständlich muss man die "Verträglichkeit" der Änderungen mit allen Datenbanken prüfen, aber für jede Datenbank per Kompilerschalter unterschiedliche, datenbankspezifische Programme zu erstellen, halte ich allenfalls für suboptimal - wirklich nur dann machen, wenn's absolut nicht anders geht.

[Bernhard Geyer]

Bei richtigen DBMS muss/sollte man als Curserlocation clUseClient verwenden bei Access als Desktop-DB clUseServer.

Ansonsten schmeiß ich mal das Bridge-Pattern ins Rennen. Ist zwar erstmal etwas aufwand, aber abschließend hast du ein System das ohne Kompilerschalter mit unterschiedlichen DBMS zusammenarbeitet.