Exception beim 2. Aufruf von ADOQuery.Close unter WinNT4 (Win2000 nicht)

[Tobias Dyrks]

Hallo,
ich habe ein Problem mit den ADO-Komponenten von Delphi 5 Ent. beim Zugriff auf eine ACCESS 2000 Datenbank.

Wenn Anweisungen (s.u.) ausgeführt werden, gibt es erst einmal keine Probleme.
Wird der Anweisungsblock allerdings ein zweites Mal ausgeführt, tritt bei der CLOSE-Anweisung eine Exception auf:

"Es ist eine Exception vom Typ EOleException aufgetreten. Entweder BOF oder EOF ist true, oder der aktuelle Datensatz wurde gelöscht. Der angeforderte Vorgang benötigt einen aktuellen Datensatz."

Im weiteren Verlauf tritt noch die Fehlermeldung "Operation ist auf einer geschlossenen Datenmenge nicht ausführbar", die wohl auf den ersten Fehler zurückzuführen ist.

Der Witz an der Sache ist, dass unter Windows 2000 alles fehlerfrei funktioniert. Beim Test unter NT4 kam es dem beschriebenen Problem. Unter NT4 habe ich die MDAC_typ.exe von der Delphi 5 CD installiert.

ADOQuery_.Close; //hier tritt eine Exception beim 2.Aufruf auf

//SQL-Anweisung usw.

ADOQuery_.Open();

ADOQuery_.First;
while not ADOQuery_.Eof
//usw...
ADOQuery_.Next;

//----------------------------------------------

Für Hinweise oder Ratschläge wäre ich sehr dankbar!

Tobias Dyrks

[Andreas Kosch]

Hallo,

auf der Delphi-CDROM befindet sich <b>MDAC 2.1</b>, während zusammen mit Windows 2000 statt dessen <b>MDAC 2.5</b> installiert wird. Um das <i>Entweder BOF oder EOF ist true</i>-Problem zu lösen, sollte über CodeCentral (http://codecentral.borland.com/codecentral/ccweb.exe/author?authorid=4745) das <b>ADO Express-Patch</b> vom 13.10.2000 heruntergeladen und installiert werden.

P.S: Warum wird TADOQuery verwendet? TADODataSet ist in jedem Fall besser ;-)
&#10

[Tobias Dyrks]

Vielen Dank für den schnelle Hilfe!

(AdoDataSet):<p>
Mir hat leider noch niemand ein Andreas Kosch-Buch zu dem Thema geschenkt, um das besser beurteilen zu können... ;-)

Gruß,
Tobia

[Andreas Kosch]

Hallo,

das erste Buch, in dem ADO nicht nur am Rande vorkommt, ist ja auch erst seit einigen Tagen erhältlich (<i>COM/DCOM/COM+ mit Delphi</i>). Aber was nicht ist, kann ja noch werden ;-

[Roland Best]

<< Warum wird TADOQuery verwendet? TADODataSet ist in jedem Fall besser ;-) >>

hallo Herr Kosch, liebe Kollegen,

ich steige gerade auf Delphi um und möchte mir gerne so wenig wie möglich zukunftsträchtige Fehler aneignen. Warum ist Dataset besser als Query?
Und: wir überlegen, für das Menüsystem (Hauptprogramm) und pro Programm-Modul je ein Datenmodul anzulegen. Sollten die System-Queries besser im zentralen Datenmodul liegen oder lieber auf der jeweiligen Form (bzw. im entsprechenden Datenmodul) wo sie benötigt werden? Z.B. Mitarbeiter-Query auf der Login-Form

[BlueBit]

Hallo Roland,

auf jeden Fall sollte man immer die ADODataset's verwenden, die anderen Komponenten sind eigentlich nur aus Kompatiblität zur BDE entstanden, und sollten somit einen Umstieg von der BDE auf ADO erleichtern.

TADODataset beinhaltet den vollen Umfang was ADO bietet, mit dieser Komponente kann so gut wie alles umgesetzt werden. Ob direkter Zugriff auf eine Tabelle oder ein SELECT per SQL. Wenn Du ADODataset einsetzt ist die wahrscheinlichkeit sehr gering vor irgendwelche Wände zu laufen. Wenn man sich den Ursprung von ADO anschaut, ich meine die VB Beispiele. Dann kann man sehr schnell erkennen, das eigentlich ausschließlich Connection und das RecordSet verwendet wird. Und dieses ist in Delphi TAdoConnection und TAdoDataset.

Und was die Datenmodule angeht, das ist so eine Sache. Bei großen Projekten werden die Datenmodule sehr unübersichtlich. Ab Delphi 6 ist das auf jeden Fall besser gelöst. Auch die logische Folge, das für eine Tabelle eine DataSource Komponente benötigt wird wurde in Delphi 6 eingebaut. Wenn Du also größere Projekte planst und noch die Möglichkeit hast auf Delphi 6 umzusteigen. Ist das auf jeden Fall empfehlenswert. Aber ich glaube man sollte noch ein wenig warten, da Delphi 6 gerade erst erschienen ist. Es gibt wahrscheinlich noch einige Fehler.

Ich arbeite sehr viel mit Vererbung auf der Formularebene und mit Frames. Und meiner Meinung ist es besser die DataSet's direkt auf dem Formular oder dem Frame zu setzen. Somit kann während der Entwicklungszeit auch auf die Strukturdaten problemlos zugegriffen werden. Aber ich habe es bisher auch etwas anders gelöst, denn ich habe einen eigen Constructor geschaffen der als Parameter das entsprechende DataSet mitbekommt. Der Rest wird dann zur Laufzeit generiert.

Aber es gibt natürlich auch Nachteile wenn man die Datenset's direkt auf das Formular oder Frame setzt. Denn bei größeren Projekten kann es immer mal vorkommen das sich die Tabellenstruktur ändert. Wenn Du z.B. den Kundenstamm in ein zentrales Datenmodul legst ist es einfach, wenn sich was ändert muss eben nur dieses Datenmodul angepasst werden. Wenn du wiederrum das DataSet Kundenstamm immer wieder kopierst und in der gesamten Applikation verteils, dann wird das bei einer Strukänderung problematisch und die Wahrscheilichkeit das Du was vergisst ist auch releativ hoch. Also Tabellen die häüfiger verwendet werden sollte man zentralisieren, wie z.B. Kundenstamm oder Artikelstamm. Dateien die eben nicht so oft vorkommen wie z.B. Kundenkontakte kann man direkt in ein Formular oder Frame legen.

Delphi ist ein sehr offenes und freies System, das hat vor- und nachteile. Denn man sollte auf jeden Fall Ordnung halten. Das wiederrum heist den Code zu zentralisieren. Auf jeden Fall mit Aktionslisten arbeiten und die Vererbung ausnutzen. Das Rad nicht immer neu erfinden. Eine zentrale Logic für die Datenverwaltung ist auch von großer Bedeutung. Ich habe z.B. in meinen Delphi Applikationen nur ein Formular was die normale Dateiverwaltung erledigt. Für die Detaildatensätze gibt es ein Frame was sich um die Verwaltung der Detaildatensätze kümmert. Auf keinen Fall solltest Du anfangen Codeteile zu kopieren. Aber ansonsten ist Delphi ein sehr mächtiges Werkzeug, denn es existieren sehr viele nützlich Komponenten von Drittanbietern. Diese steigern die Leistungsfähigkeit der Applikation und man kann sich dadurch auf des wesentliche konzentrieren.

Achso, wenn Du am Anfang Fehlermeldungen bekommst, also Adressverletzungen etc. Dann solltest musst Du dich näher mit Object Pascal beschäftigen. Der häufigste Fehler leigt meistens darin, das man auf Speicherbereiche (Objekte) zugreift die noch nicht installiert sind. Aber zum Glück gibt es ja den Debugger, was aber kein Allheilmittel ist.

Okay, viel Erfolg beim Umstieg auf Delphi