Feststellen, ob TTable oder TAdsTable

[FBrust]

Hallo,

durch einen Umstieg von der BDE auf den Advantage Database Server wird es eine Zeitlang beide Tabellentypen im Programm geben.

Nun gibt es Routinen, bei denen ich unterscheiden muss zwischen einer TTable der BDE und einer TAdsTable.

Wie kann ich denn herausfinden, von welchem Typ eine Tabelle ist?



Gruß
Frank

[shmia]

Zitat von FBrust:

durch einen Umstieg von der BDE auf den Advantage Database Server wird es eine Zeitlang beide Tabellentypen im Programm geben.

Nun gibt es Routinen, bei denen ich unterscheiden muss zwischen einer TTable der BDE und einer TAdsTable.
Wie kann ich denn herausfinden, von welchem Typ eine Tabelle ist?

Delphi-Quellcode:

if tabelle17 is TTable then
begin
   // BDE
end
else if tabelle7 is TAdsTable
begin
   // ADS
end;

[FBrust]

ach so einfach?

na dann:

und:


Danke für die Antwort


Gruß
Frank

[Quake]

oder
if tabelle17.class = TTable then oder
if tabelle17.classname = 'TTable' then

[Quake]

Habe gerade festgestell, dass es einen Unterschied gibt zwischen shmias und meiner Methode.

z.B.

Angenommen Edit ist ein TEdit

Edit is TEdit -> true
Edit is TWinControl -> true

Edit.Class = TEdit -> true
Edit.Class = TWinControl -> false

bye

[phXql]

Zitat von Quake:

Habe gerade festgestell, dass es einen Unterschied gibt zwischen shmias und meiner Methode.

z.B.

Angenommen Edit ist ein TEdit

Edit is TEdit -> true
Edit is TWinControl -> true

Edit.Class = TEdit -> true
Edit.Class = TWinControl -> false

bye

is berücksichtigt auch alle geebrten klassen, .class macht das anscheinend nicht...

[Robert_G]

Vor allem ist die Prüfung auf den string des Klassennamens schon ziemlich ... krass.
Während die normale, lesbare und vom Compiler geprüfte Variante (IS Operator) nur eine klitzekleine Operation durchführen muss, ist bei deiner Variante gleich ein ganzer Stringvergleich fällig.

btw: Leitet die TAdsTable nicht von der TTable ab? Oder haben sie nicht einen kleinsten gemeinsamen Vorfahren, der die benötigten Eigenschaften und Methoden mitbringt?
Dann dürfte es doch ziemlich easy sein nur den im Code zu nehmen.

[Union]

Zitat von Robert_G:

Vor allem ist die Prüfung auf den string des Klassennamens schon ziemlich ... krass.
Während die normale, lesbare und vom Compiler geprüfte Variante (IS Operator) nur eine klitzekleine Operation durchführen muss, ist bei deiner Variante gleich ein ganzer Stringvergleich fällig.

btw: Leitet die TAdsTable nicht von der TTable ab? Oder haben sie nicht einen kleinsten gemeinsamen Vorfahren, der die benötigten Eigenschaften und Methoden mitbringt?
Dann dürfte es doch ziemlich easy sein nur den im Code zu nehmen.

Die haben TDataSet als Vorfahr. Und deshalb sollten die Funktionen dann auch so programmiert werden.

TDataSet->TBDEDataSet->TDBDataSet->TTable
TDataSet->TAdsExtendedDataSet->TAdsTable

[joachimd]

Zitat von Robert_G:

Leitet die TAdsTable nicht von der TTable ab?

Gott bewahre...den ganzen BDE Quatsch mitschleppen? Was wäre das dann für eine Alternative?
Übrigens: Wir hatten schon oft Anfragen, warum ADS denn die BDE weiterhin benötigt. Die Lösung bestand immer in einer Unit (dbtables), welche die Anwender in der uses-Klausel vergessen haben.
Merke: Wenn BDE-Frei, dann auch alle BDE-Units entfernen! (und weil es so wichtig ist, gleich nochmal ein paar Ausrufezeichen!!!).

[Robert_G]

*In Deckung gehe*

sorry, TTable gehört zu den Dingen, die ich freiwillig wohl niemals anrühren werde.
In der Hinsicht bin ich ganz stolz darauf inkompentent zu sein.