Delphi 6 + ADO + Installshield 3.03

[Klaus Jäde]

<B> Hilfe Herr Kosch ! </B> <P>
Ich habe mit Delphi 6 ein Programm entwickelt und wegen des notwendigen Verzichts auf die BDE mehrere TADOConnections (auftragsgemäß mit dBase-Dateien) und dem Connectionstring:<P><B>
Provider=MSDASQL.1;Persist Security Info=False;Data Source=dBASE-Dateien;Extended Properties="DSN=dBASE-Dateien;DBQ=C:\MEIN-DATEN-VERZEICHNIS;DefaultDir=C:\MEIN-DATEN-VERZEICHNIS;DriverId=533;MaxBufferSize=2048;PageTi meout=5;";Initial Catalog=C:\MEIN-DATEN-VERZEICHNIS<P></B>

, TADODatasets und TADOCommands eingesetzt. Das Programm funktioniert auf dem Entwicklungsrechner (Windows2000) ganz einwandfrei. <P>
In dem Augenblick, wo ich das Programm auf einen anderen Rechner (Windows 98 und Windows XP) installiere und starte, stürzt das Programm mit unterschiedlichen Fehlermeldungen (meistens Stack-Überlauf, machmal ohne jede Fehlermeldung) ab. Dies passiert offensichtlich <B>bevor</B> ich die 1. Zeile im FormActivate aufrufe (also vor dem Initialisieren der TADOConnections und Öffnen der TADODatasets). Das FormCreate wird noch ordentlich abgearbeitet.<P>
Erst wenn ich das Programm auf den anderen Arbeitsstationen (Windows 98/Windows XP) compiliere, läuft es auch dort einwandfrei.<P>
Da ich beim Anwender schlecht Delphi installieren kann, damit das Programm läuft, bin ich ratlos, da ich keinen Programmfehler ausmachen kann.<P>
Ich dachte dann an ein Setup-Tool und stellte dies mit der Borland-Limited- Edition von Installshield her. Dabei kann man ja ADO und MDAC mit installieren. Aber auch das hatte auch keinen Erfolg.<P>
Meine Frage an Herrn Kosch (oder jeden anderen Profi). Welche Objekte/Merge-Module müssen denn mit Installshield auf den anderen Rechnern installiert werden, damit die Programme auch auf einem "nackten" System laufen ? Oder gibt noch andere Lösungsansätze ?
<P>
Vielen Dank für die gewohnte schnelle Hilfe !<P>
Klaus Jäde

[Michael Seehuber]

- Schon mal die ADO version auf dem Testrechner geprüft ....
und gegebenenfalls MDAC nachinstallieren
www.microsoft.com/dat

[Michael Seehuber]

Da versucht wird, per ODBC-Treiber auf die dBase Daten zuzugreifen, stellt sich die Frage, welche weiteren Treiber ausser ADO noch geladen werden und ob nicht hier das Problem liegt.

Zur Sicherheit würde ich mit einem ProcessMonitor auf dem Entwicklungsrechner die geladenen DLL kontrollieren und ob diese auch auf dem Testrechner vorhanden sind.

( www.sysinternals.com

[Michael Seehuber]

Unter

http://www.installshield.com/downloads/isd/mm/modules.asp?source=support_central&product=wind

können weitere Merge Modules heruntergeladen werden. z.B auch für die neuere MDAC26 und MDAC2

[Klaus Jäde]

<B>Delphi 6 + ADO + Installshield 3.03</B><P>
ich habe das Problem der Installation auf ein "nacktes" System bisher nur so lösen können, daß ich über Installshield die BDE mit installiere. Jetzt läuft das Programm einwandfrei. Das kann doch wohl nicht war sein. Der einzige Grund ADO zu installieren ist doch die extrem störanfällige BDE zu vermeiden(wenn auch andere Programme die BDE verwenden). Und jetzt funktioniert ADO nur, wenn auch gleichzeitig die BDE installiert wird.<P>
Delphi 6 Enterprise (Upgrade-Preis € 3.096,00) scheint ein riesengrosser Schritt rückwärts in die 80er Jahre zu sein, wo sich Borland einen Teufel um Datenbankapplikationen kümmerte, die auch damals schon 99% aller Anwendungen ausmachte.<P>
Kann mir jemand sagen, was dieser Schwachsinn soll, oder liegt der Denkfehler bei mir

[Michael Seehuber]

Hallo,

wenn man TADOConnection, TADODataSet und TADOCommand einsetzt, wird definitiv keine BDE benötigt. Ich verwende ADO für ein größeres Project und muss zudem zwischen verschiedenen SQL-Servern umschalten können.

Delphi 6 Enterprise ist zwar nett, aber für ADO nicht nötig.

Das Problem liegt wohl eher daran, daß ADO wahrscheinlich die BDE benutzt, um die dBase Daten anzusprechen. Alternativ verwendet man am besten entweder eine nativen dBase ODBC Treiber ( "Intersolv" ) oder falls auschließlich dBase Daten verwendet werden z.B. Halcyon ohne ADO.

Michae

[Andreas Kosch]

Hallo,

getreu nach "Murphys Gesetz" werden die interessantesten Fragen immer dann gestellt, wenn ich zu den Entwickler Tagen eine Woche "offline" bin :-)

>Das kann doch wohl nicht war sein. Der einzige Grund ADO zu <br>
>installieren ist doch die extrem störanfällige BDE zu vermeiden

Das Verhalten hängt von der installierten MDAC-Version ab. Ab der Microsoft Jet Engine 4 greift Microsoft für den Schreibzugriff auf eine dBASE-Tabelle auf die BDE zu. In der Zwischenzeit wurde dies jedoch wieder geändert.

>Kann mir jemand sagen, was dieser Schwachsinn soll, oder liegt der Denkfehler bei mir ?

Der "Denkfehler" besteht darin, mit ADO auf eine dBASE-Tabelle zuzugreifen. Wenn schon die BDE entsorgt wird, sollte dies auch für dBASE/Paradox gelten, denn für beide Datenbankformate stellt Microsoft nur einen Minimal-Treiber für Lesezugriffe (JET Engine 4) zur Verfügung. ADO ist nur dann sinnvoll, wenn es einen Treiber gibt. Da ab MDAC 2.7 auch die ODBC-Treiber auf der "Abschussliste" stehen (siehe ADO.NET), würde ich nur Datenbanken einsetzen, für die es einen echten OLE DB Provider gibt