Programmcrash & Drwatson32

[enricoffo]

Guten Morgen,

ich wollte mal die Problemlösung posten, nur zur allgemeinen Information.

1. Danke für den Tipp mit den MAD-Tools.
2. Mein Programm kam ja nicht wirklich weit, Dr Watson war ja wesentlich schneller.

Dank der MAD-Tools ging es blitzschnell. Da mein Programm über DAO auf eine Access-DB zugreifen sollte braucht es ja ein installiertes DAO im System.
Es war auch installiert. Leider war aber die "DAO360.dll" nicht registriert(altes M$ Problem und auch gut erklärt in irgendeinem KBxxxx-Teil). Tja, eigene Dummheit.
Nachdem dann beim Datenbank öffnen eine EDatabaseException kam (no DAO), war die Lösung ziemlich easy. Regsrv32 DAO360.dll und siehe da, es geht...


Aber trotzdem würde es mich mal interessieren, wie man diesen Microsoft Dr Watson-Report auswerten kann und diese Hexadresse, wo der Fehler auftrat im Delphicode finden kann.
Wenn da jemand ne Idee hätte oder eine Anregung, wäre echt toll.


Herzlichen Dank nochmal für die schnelle Hilfe an Euch alle.

[Bernhard Geyer]

Zitat:

Zitat von enricoffo

Da mein Programm über DAO auf eine Access-DB zugreifen sollte braucht es ja ein installiertes DAO im System. ...

Und wieso nutzt Du noch DAO? AFAIK darf man das nur installieren (wenn es nicht aufgrund eines "Installationsfehlers" von MS nicht aktiv ist wenn man eine Anwendung mit einer MS-IDE mitverteilt. Wie wäre es mit einem Wechsel nach ADO (Auch wenn MS eh schon den Tod von ADO und Access als Datenbank vorranschreiten läßt).

Zitat:

Zitat von enricoffo

Aber trotzdem würde es mich mal interessieren, wie man diesen Microsoft Dr Watson-Report auswerten kann und diese Hexadresse, wo der Fehler auftrat im Delphicode finden kann.

Das bringt dir nur etwas wenn auf beiden Rechner dein Programm über die gleichen Speicheradressen geladen wird. Dann kannst Du dein Programm in der IDE starte und den Menüpunkt "Bearbeiten/Laufzeitfehler suchen" anwählen. Wenn Du glück hast landest Du auf Pascal-Code. Wenn nicht dann hast Du zu wenig Debug-Infos (Debug-DCU's) in deinem "Testprogramm" und must diese Aktivieren. Alternativ schau dir mal die Jedi an. Dieses bietet komprimierte TD32-Debug-Infos und eine Hilfsdialog der dir bei einer Exeption sogar 'ne E-Mail mit Aufrufstack liefern kann.

[Christian Seehase]

Moin Bernhard,

Zitat:

Zitat von Bernhard Geyer

Das bringt dir nur etwas wenn auf beiden Rechner dein Programm über die gleichen Speicheradressen geladen wird.

Was beim normalen Start einer Exe (also nicht, z.B., über LoadLibrary um nur die Resourcen auszulesen) immer der Fall sein.
Ansonsten dürften Programme, denen man die Relocation-Table entfernt hat, um sie kleiner zu machen, auch massiv Probleme bereiten.

[enricoffo]

Also ich benutze DAO, weil man damit sehr schnell und einfach auf dBase zugreifen kann. Und das muß ich oft in der Firma. ADO ist da einfach zu langsam und TDBF bietet mir keine SQL-Abfragen.
Und extra einen SQL-Server für 'n Mücke ist doch quatsch, oder?

Was habe ich denn für Alternativen???

[Bernhard Geyer]

Zitat:

Zitat von Christian Seehase

Was beim normalen Start einer Exe (also nicht, z.B., über LoadLibrary um nur die Resourcen auszulesen) immer der Fall sein.
Ansonsten dürften Programme, denen man die Relocation-Table entfernt hat, um sie kleiner zu machen, auch massiv Probleme bereiten.

Ok. Sagen wir lieber so das dieses Problem eher bei den noch zusätzlichen (Delphi-)DLL's auftritt da diese ja (wenn man nichts ändert) in der IDE die gleiche Startadresse bekommen.

Zitat:

Zitat von enricoffo

Also ich benutze DAO, weil man damit sehr schnell und einfach auf dBase zugreifen kann.

Kannst Du doch auch mit ADO wenn du dort die Jet-Engine benutzt.

Zitat:

Zitat von enricoffo

ADO ist da einfach zu langsam

Halte ich für ein Gerücht. Da bei beiden die Jet-Engine ist die verwendet wird kann es eigentlich nur an unpassenden Default-Einstellungen von ADO (Servercurser = UseClient, welche man bei Access auf UseServer umstellen sollte). Ansonsten sollten beide Zugriffe ähnlich schnell sein.

Zitat:

Zitat von enricoffo

Und extra einen SQL-Server für 'n Mücke ist doch quatsch, oder

Hab ich ja auch nicht gesagt: ADO != MS SQL-Server.