Sie sind aktuell nicht angemeldet.

Funktionen: Einloggen  |  Neu registrieren  |  Suchen

VB6 MySQL DAO Win7 32bit Connection Problem
Autor: erich1961
Datum: 08.05.14 08:46
Hallo! Ich habe den MySQL ODBC 3.51.30.00-Treiber installiert, im Datenquellenadministrator funktioniert in der Benutzer-DSN der Test einwandfrei. Ich habe die MSRDO20.DLL Dateiversion 6.0.88.62 im system32 stehen und mit regsvr32 erfolgreich registriert. Ich verweise in meinem Programm auf die DAO 3.6. Der Connectionstring ist lt. Handbuch MySQL 25.1.4.5.1 aufgebaut. Programm baut unter XP ohne Zicken die Verbindung auf und läuft. Unter Win7 bekomme ich die Fehlermeldung 3146. Was mir aufgefallen ist, wenn ich mit dem Datenquellenadministrator eine Ablaufverfolgung starte, dann zeichnet diese den Verbindungsaufbau via Test im Benutzer-DSN auf, aber beim Aufruf des VB6-Programms wird noch nicht mal eine LOG-Datei eröffnet.

Re: VB6 MySQL DAO Win7 32bit Connection Problem
Autor: erich1961
Datum: 08.05.14 10:10
Kurze Anmerkung noch: Von MS-Access 2010 habe ich eine Verbindung zur Datenbank aufbauen können, da wird einfach die Computerdatenquelle angegeben und ich habe sofort Zugriff auf die Daten der MySQL-DB.

Verdacht für Fehlerquelle
Autor: erich1961
Datum: 09.05.14 11:43
Da ich DAO nutze und dementsprechend über MDAC die MySQL-Datenbank via ODBC aufrufe, habe ich den Verdacht, dass dort der Hase im Pfeffer liegt. Win7 Sp1 unterstützt MDAC nicht mehr, somit laufen die Aufrufe in Leere? Kann das jemand bestätigen, und wenn ja, welche Abhilfe gibt es? Dazu als Erklärung, ich habe einen Kunden mit mehreren Filialen. Die MySQL-Datenbank dient als Basis für gemeinsame Daten. Über eine Routine gleiche ich diese Daten mit der lokalen Access-Datenbank ab. Eine Möglichkeit, die ich mir vorstellen könnte, wäre, eine zusätzliche Accessdatenbank zu erstellen, die die MySQL-DB via Verknüpfung einbindet und diese DB dann dementsprechend aufzurufen und abzufragen. Nachteil wäre die Installation von MS-Access oder gibt es auch da Alternativen? Permanente Verbindungen zum INet sind nicht gewollt. Ich könnte mir auch die Auslagerung der Routine zum Abgleich in ein eigenes Programm vorstellen. Dieses müsste dann gleichzeitig auf Access97.mdb und MySQL zugreifen, geht das überhaupt mit VB6?

Lösung in Sicht
Autor: erich1961
Datum: 10.05.14 17:12
Hallo! Ich denke, ich bin dabei das Problem zu knacken. Mit Microsoft ADO 6.0 und ADO bekomme ich Zugriff auf MySQL, die Routine wird halt ausgelagert und dann bei Bedarf (Vista und höher) aufgerufen. Gemerkt habe ich das, nachdem ich VB6 auf Win7 installiert habe. Habe vorher VB6 in einer VM mit XP ausgeführt. Dabei habe ich dann festgestellt, dass sich SP4 /SP6 nicht installieren lässt, mit dem Hinweis, dass sich MDAC nicht auf dem Rechner befindet, MDAC liess sich auch nicht nachträglich installieren. ODBC über DAO setzt MDAC voraus. Der MDAC ist ersetzt worden durch WDAC oder so. Konnte also so nicht gehen. Allerdings tauchen jetzt andere Probleme auf wie API's, die nicht mehr laufen wie SHGetSpecialFolderLocation und ersetzt werden wollen durch SHGetFolderPath ...

Problem gelöst
Autor: erich1961
Datum: 13.05.14 21:18
Die Lösung, die ich angedacht hatte funktioniert soweit, mal abgesehen davon, dass ADO ein wenig zickig ist. On error resume next ist nicht ganz so nach meinem Geschmack.

Re: Problem gelöst
Autor: Franki
Datum: 15.05.14 00:30
Hallo, On Error im Code kann aber helfen den Fehler zu finden. Man kann ja den Fehler auswerten sowohl nach Fehlernummer als auch Fehlerbeschreibung und im Code darauf reagieren. Und auch bei Bedarf den Fehler mit .Clear zurücksetzen. Ich verwende das sehr gerne wenn die Möglichkeit besteht, dass ein Fehler auftritt der anders nicht abfangbar ist. Dann kann ich im Programm reagieren, dem User eine dem Fehler entsprechende Meldung geben und das Programm läuft weiter (zwar eingeschränkt, aber der User weiß was Sache ist) Gruß Frank

Kommt drauf an
Autor: erich1961
Datum: 15.05.14 13:43
Manchmal machen auch on error resume next einen Sinn: wie bei: Private Function DirExists(ByVal Path As String) As Boolean On Error Resume Next DirExists = CBool(GetAttr(Path) And vbDirectory) On Error GoTo 0 End Function oder Private Function IsIDE() As Boolean On Error Resume Next Debug.Print 1 / 0 IsIDE = (Err <> 0) On Error GoTo 0 End Function Aber den User mit err.number oder err.description zu verwirren, tue ich nicht, das macht nur Ärger. Ich mach das lieber so: Private Sub WriteErrorData(ByVal Text As String, ByVal FehlerMeldung As String, ByVal Fehler As Long) Dim i As Integer Dim version As String Dim VistaPfad As String version = App.Major & "." & App.Minor & "." & App.Revision VistaPfad = GetFolder(sfidCOMMON_APPDATA) On Error GoTo errhand Fehlernummer: " & Trim(Fehler) i = FreeFile Open (VistaPfad & "\text\error" & Date & ".txt") For Append As i Print #i, version & ";" & Trim(Date) & ";" & Trim(Time) & ";Mandant:" & MandantenNummer & ";" & Text & ";" & FehlerMeldung & ";Fehlernummer: " & Trim(Fehler) Close #i If IsIDE = True Then Beep Debug.Print FehlerMeldung End If On Error GoTo 0 If Fehler = 0 Then Exit Sub Exit Sub errhand: ... Aufruf geht folgendermassen: Call WriteErrorData("Datenschreiben ÄndereLokal " & sql, Err.Description, Err.Number)

Sie sind nicht angemeldet! Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden. Einloggen  |  Neu registrieren

Funktionen:  Zum Thema  |  Gesamtübersicht

Suchen