Probleme mit eigener Implementierung von DbDataAdapter, IDbDataAdapter

[Markus Jankowski]

Ich versuche einen eigenen ADO.NET DataAdapter (für Lotus Domino) mit Delphi 8.Net SP2 zu erstellen.
Alle vorgelagerten Objekte (Connection, Command, DataReader) hab ich bereits erstellt und getestet.

Die eigene Implementierung des DataAdapters erbt von DbDataAdapter und Implementiert IDbDataAdapter.
Der Compiler verarbeitet meine Unit klaglos, jedoch erscheint bei der Instanzierung folgender Laufzeitfehler:

System.TypeLoadException

Message :

"Signatur of body and declaration in a method implementation do not match. Type UNSFData.TNSFData..."

Zum testen hab ich ein neues Projekt angelegt, das nur ein Formular und eine Unit "UNSFData" verwendet.
In der Unit wurde nur TNSFData = class(DbDataAdapter, IDbDataAdapter) mit den erforderlichen (leeren) Methodenrümpfen implementiert.

[Andreas Kosch]

Hallo,

die Typprüfung der CLR ist deutlich strenger als wir das bisher von Delphi gewohnt waren. Für die CLR ist ein Type nur dann identisch, wenn die Bestandteile <i>Assembly-Name</i>, <i>Version</i>, <i>AssemblyCulture</i> und <i>PublicKeyToken</i> identisch sind.

Somit reicht es nicht mehr aus, den Type einfach im 2. Programm nochmals zu deklarieren. Statt dessen müssen beide Teile die gleiche Assembly als Verweis einbinden, in der der gemeinsam genutzte Type einmalig deklariert wird.

Ein zweites Problem besteht darin, das der Compiler in bestimmten Fällen die Methoden-Signatur hinter den Kulissen ohne Vorwarnung ändert. Dies passiert zum Beispiel dann, wenn ein Parameter über <b>const</b> gekennzeichnet wird.

a) Aufruf .NET -> Win32: Damit aus der .NET-Anwendung heraus die Abwärtskompatibilität über P/Invoke-Aufrufe erhalten bleibt, behält Delphi 8 die so genannte »const-means-by-ref semantics« bei. Das gleiche gilt für Interfaces, damit Win32-Code auch dann noch funktioniert, wenn Const eigentlich Ref meint (..where the const param means by ref...).

b) Aufruf .NET -> .NET: Const-Parameter sind mit pass-by-value-Parametern identisch, daher kollidiert die .NET-Welt mit dem Delphi 8-Kompatibilitätsmodus. Dies hat zur Folge, dass im Worst Case die folgende Regel gilt: <br>
a) const im Interface = const-by-ref <br>
b) const in der Methode = const-by-value<br>

Delphi 8 bevorzugt in der aktuellen Fassung den Aufruf der "alten" Sachen (.NET ruft Win32 auf). Erst in der nächsten Delphi-Version soll ein Compiler-Schalter die Kontrolle über das Verhalten bei const-Parametern erlauben.

In einem Newsgroup-Beitrag hat das ein Borländer in den folgenden kurzen Satz zusammengefasst: "<i>"const" within an Interface is not identical with "const" within a method declaration of a class </i>"

[Markus Jankowski]

Das heist, ich kann mit Delphi 8 keine Abbleitung /Implementierung für DbDataAdapter/IDbDataAdapter (beide aus System.Data.dll) erstellen??

Ich habe versucht das Beispiel aus dem Net Framework SDK in Delphi zu implementieren:

"Programmieren mit Net Framework/Implementieren eines .NET Framework-Datenproviders/Implementieren eines DataAdapters [C#]"

const Parameter konnte ich im Interface nicht erkennen.
Nur einige Methoden haben Arrays (array of DataTable) als Rückgabewerte!!

[Andreas Kosch]

Hallo,

&gt;Das heist, ich kann mit Delphi 8 keine Abbleitung ....

das Implementieren von IDbDataAdapter habe ich selbst noch nicht ausprobiert, so dass ich nicht sagen kann, ob das in diesem konkreten Fall generell nicht möglich ist. Meine Antwort sollte nur die Sonderwege in Erinnerung bringen, die Borland im Kompiler untergebracht hat, damit sich alte Anwendungen möglichst ohne große Änderungen in Delphi 8 kompilieren lassen. Ich habe auch einige C#-Beispiele am Lager, die ich mit Delphi 8 aufgrund der Einschränkungen nicht nachbauen kann.

P.S: Wenn man einen Blick in das Source-Verzeichnis von Delphi 8 wirft, findet man dort stellenweise C# vor. Also greift auch Borland im Einzelfall immer zu der Sprache, die für eine bestimmte Aufgabe am Besten geeignet ist