Speickerleck BDP --> ADO.NET --> Firebird

[Alex2.2]

Hallo Community benutzer

Ich habe ein reletive spezielles Problem das solwohl hier als auch zum Thema Datenbanken gehören könnte:
Ich habe im .NET Framework 1.1 (bitte nicht lachen, mein Boss will das eben so) mit einer Firebird Datenbank und BDP ein Project auf gebaut (Ich benutze noch Delphi 2006). Das auch vernünftig läuft, bis auf ein Problem, das nun aufpoppt. Der Heap des Workerprozesses wächst und wächst und ... Nach langen untersuchungen meines Codes und einigem Suchen (googlen) finde ich heraus daß der ADO DataReader (auf ADO baut BDP auf) bei jedem Lesen ein Speicherleck von round about 100Bytes produziert, dieses aber nur mit Firebird.

Ich habe dieses mit einem kleinen Testprogramm auch verifizieren können. Mit Entsetzen mußte ich bei meinen Untersuchungen dann auch noch Feststellen das auch fbProvider.NET auch auf ADO aufsetzt womit wohl auch diese LÖösung ausgeschlossen zu sein scheint.
Meine Fragen:
- Hat jemand Kenntnis ob es für dieses Problem bereit eine Lösung gibt?
- gibt es ein Bugfix für ADO?
- Was passiert wenn man mit ODBC arbeitet?
- Welche Wege gibt es ohne ADO mit Firebird zu arbeiten.

Ich bin für jede konstruktive Antwort sehr dankbar.

Bernd

[Bernhard Geyer]

ADO != ADO.NET. Die beiden Techniken haben bis auf 3 gleiche Buchstaben am Anfang nix gemeinsam. Also: Meinst du mit ADO wirklich native ADO oder ADO.NET?

Und schmeiß am besten BDP weg. Ist AFAIK mit Delphi.NET eh gestorben und würde einen späteren Port nach Delphi.Prism behindern.

[Jürgen Thomas]

Hallo,

da Du in der Überschrift von ADO.NET sprichst, nehme ich an, dass Du das meinst.

ADO.NET bietet die Basisklassen für den DB-Zugriff, z.B. DbConnection oder DbCommand. Jeder "konkrete" DbProvider bietet für sein DB-System passende Ableitungen. Der Odbc-Provider ist eine Minimallösung, die nur in seltenen Ausnahmefällen sinnvoll ist (wenn es nichts anderes gibt). Für Firebird ist der Firebird ADO.NET Provider (bei NET 1.1 in der Version 1.7) das richtige System.

BDP ist eine Borland-eigene Notlösung, die die Unterschiede zwischen den DbProvider verschleiern wollte, aber genau aus diesem Grund nicht besser ist als Odbc.

Gruß Jürgen

[Alex2.2]

Bernhard: Das löst nicht mein Problem. Borland.Prism habe ich nicht und weiß auch nicht, ob ich es jemals haben werde. Ich brauche eine Lösung bei der ich möglichst einfach auch andere DBs, wie MSSQL oder MySQL, etc., verbinden kann. Das hätte sich in meiner leider sehr alten und beschränkten Umgebung (.NET 1.1, Delphi 2006 ... alles veraltet) gut mit BDP lösen lassen.
BDP setzt auf ADO.NET auf und erweitert dessen Funktionalität.
Daher nochmals: Schmeiss weg und mach neu ist nicht.

Jürgen: Bist du sicher, das der fbProvider auch nicht das selbe Problem produziert?

Bernd

[Jürgen Thomas]

Zitat von Alex2.2:

Jürgen: Bist du sicher, das der fbProvider auch nicht das selbe Problem produziert?

Nein, aber ich könnte mir vorstellen, dass IBExpert hier oder in seinem eigenen Forum Genaueres weiß (Holger arbeitet mit allen Versionen von FB und NET). Jürgen

[Alex2.2]

Also mein Kollege,
der eine andere Anwendung geschrieben hat, setzt den fbProvider ein. Wir sind gerade am testen, ob der das selbe Problem produziert. Ich jeden falls danke Dir erstmal.

Bernd