Zugriff auf MS-SQL-Dartenbank unter W-7

[uwe Gutsche]

Hallo an Alle,

da in dieser NG überhaupt noch jemand postet, hoffe ich, dass mir hier
jemand helfen kann.

Das Problem ist schnell beschrieben:
Ein mit VB6 geschriebenes Programm (Datenbankzugriff auf MS-SQL-Server)
funktioniert unter XP einwandfrei.
Nun muss es auf W-7 Maschinen (64Bit) laufen, und beim ersten Zugriff
auf die Datenbank stürzte das Programm mit "Fehler 3633: kann
MSRDO20.dll nicht öffnen" ab. Daraufhin habe ich die "MSRDO20.dll" im
Install-Scipt mit hinzugefügt, aber jetzt ist der Fehler: "3146".
MS-knowledgebase meint dazu, dass die ODBC.dll von Version 1.xx (16Bit)
auf 2.xx (32Bit) upzudaten ist. ??
Ich denke, das ist nicht mehr ganz aktuell, zumal ich auf dem ganzen W-7
System keine "ODBC.dll" finden kann (nur:"ODBC32.dll", "ODBCbcp.dll",
"ODBCconf.dll" und so weiter..)
Ich habe inzwischen auch versucht, das Programm mit ".NET 2003" neu zu
übersetzen, aber der Fehler ist der gleiche.

Der Quelltext sieht praktisch so aus (auch wenn das jetzt schon .NET ist):

Public wk As Workspace
Public cnMa As Connection
Public strCon As String
Public rstMa As Recordset


wk = DBEngine.CreateWorkspace("ODBCDirect", "", "",
WorkspaceTypeEnum.dbUseODBC)

On Error GoTo Err_
strCon = "ODBC;DATABASE=dbName;UID=uID;PWD=pWD;DSN=dSN"
cnMa = wk.OpenConnection("ConMa",
DriverPromptEnum.dbDriverNoPrompt, False, strCon)

' Der Fehler entsteht in der folgenden Zeile '
rstMa = cnMa.OpenRecordset("SELECT Ma_Name, Ma_Vorname FROM
Mitarbeiter WHERE ......)
....
Goto Exit_

Err_:
MsgBox("Fehler " & Err.Number & " (" & Err.Description & ")",
vbApplicationModal + vbExclamation, )

Exit_:
On Error GoTo 0

Ich probiere jetzt schon seit einigen Wochen, komme aber immer an der
gleichen Stelle nicht weiter.
Ich vermute, dass es am 64Bit-System liegt, weil es unter XP ja geht.

Hat irgend jemand eine hilfreiche Idee?

Im Voraus schon mal Danke

Uwe

[Schmidt]

"uwe Gutsche" <***@tu-dresden.de> schrieb

Die Antworten auf Deine Frage halten sich vermutlich
deshalb "in Grenzen", da wahrscheinlich kaum jemand
noch Applikationen "da draussen" hat, die per
DAO/ODBC gegen den MS-SQLServer arbeiten.

Bin mir ziemlich sicher, dass beim Arbeiten per
ADO/OleDB in VB6 keine Probleme auf Win7-64
(zumindest gegen den MS-SQLServer) auftreten
sollten.

Ich hab' schon ewig nicht mehr mit DAO hantiert -
und kann Dir da wenig helfen, ausser dem wahrscheinlich
wenig ermutigenden Tip, doch in der VB6-App besser
auf ADO - bzw. in der .NET-App dann besser auf
ADO.NET umzustellen, um auf den SQLServer zu-
zugreifen.

Mit ADO sollten sich dann auch eventuelle "RDO-
dependencies" in Wohlgefallen auflösen (falls
ihr das Ganze nicht hinter einem WebServer
betrieben - und RDO als AppServer-Layer
benutzt habt).

Olaf

[uwe Gutsche]

Hallo Olaf,

Post by Schmidt
Die Antworten auf Deine Frage halten sich vermutlich
deshalb "in Grenzen", da wahrscheinlich kaum jemand
noch Applikationen "da draussen" hat, die per
DAO/ODBC gegen den MS-SQLServer arbeiten.

Na gut, nicht mehr "up to date" ?
Zugegeben, ich habe mich wenig mit den Zugriffsmechanismen befasst: Zwei
Varianten (eine für Desktop-Programme - ".exe" und eine für
Netzanwendungen - ".htm / .asp") und diese werden bei mir seit Jahren
immer wieder benutzt (solange es geht).

Post by Schmidt
Bin mir ziemlich sicher, dass beim Arbeiten per
ADO/OleDB in VB6 keine Probleme auf Win7-64
(zumindest gegen den MS-SQLServer) auftreten
sollten.

Dann brauche ich eben ADO/OleDB.
Gibt es eine Art "Kochrezept" mit der ich dann wieder mehrere Programme
durchziehen kann?

Post by Schmidt
Ich hab' schon ewig nicht mehr mit DAO hantiert -
und kann Dir da wenig helfen, ausser dem wahrscheinlich
wenig ermutigenden Tip, doch in der VB6-App besser
auf ADO - bzw. in der .NET-App dann besser auf
ADO.NET umzustellen, um auf den SQLServer zu-
zugreifen.

Dann besser gleich in der .NET-App (die ist auch schon ein Stück weiter
verbessert)

Post by Schmidt
Mit ADO sollten sich dann auch eventuelle "RDO-
dependencies" in Wohlgefallen auflösen (falls
ihr das Ganze nicht hinter einem WebServer
betrieben - und RDO als AppServer-Layer
benutzt habt).

Der erste Teil (Daten speichern) ist eine reine Desktop- Anwendung, die
die Daten in eine SQL-Datenbank einsortiert.
Für das Arbeiten (Fehlersuche...) zu Hause greife ich dann auch auf eine
ACCESS-Datenbank zu:

Dim wrkODBC As Workspace
Dim rstMa As Recordset
Dim dbkMa AS Database

If InStr(sDbkMa, ".mdb") > 0 Then
Set dbkMa = OpenDatabase(sDbkMa)
ElseIf InStr(sDbkMa, "DSN") > 0 Then
Set dbkMa = wrkODBC.OpenDatabase("MaDSN", dbDriverNoPrompt, ,
"ODBC;Database=dbName;UID=uID;PWD=pWD;DSN=dSN")
End If
rstMa = dbkMa.OpenRecordset("SELECT Ma_Name, Ma_Vorname FROM
Mitarbeiter WHERE ......)

Dadurch brauche ich keine Änderungen in den Abfragen machen und die
Verwendung/Auswertung der Daten funktioniert in beiden Umgebungen.
Geht das dann bei ADO auch?
Der zweite Teil (Daten suchen und lesen) funktioniert dann übers
Intranet von jedem Arbeitsplatz aus also als .htm/-asp - Anwendung.
Wenn ich jetzt das Speichern auf .NET umstelle, kann doch (vorerst) das
Lesen im "klassischen" Stiel bleiben, denke ich.

Es wäre schön, wenn Du ein (-ige) Musterbeispiel(e) hast und dazu
notwendige Informationen z.B. muss ich irgendwelche Treiber,
Programme... dafür installieren?
Oder ein Paar Sites im Netz, wo ich das alles nachlesen kann.

Danke
Uwe

[Schmidt]

Post by uwe Gutsche

Post by Schmidt
Bin mir ziemlich sicher, dass beim Arbeiten per
ADO/OleDB in VB6 keine Probleme auf Win7-64
(zumindest gegen den MS-SQLServer) auftreten
sollten.

Dann brauche ich eben ADO/OleDB.
Gibt es eine Art "Kochrezept" mit der ich dann wieder
mehrere Programme durchziehen kann?

Da gibt es im Netz haufenweise Beispiele, wie man
mittels ADO Connections öffnet - und auf diesen
Connections dann ADO-Recordsets (inkl. Updates,
Manipulation, DataBinding dieser Container)

Schau z.B. mal auf der Seite von Peter Götz rein,
da sollten Beispiele sowohl für ADO+VB6 - als
auch für ADO.NET+VB.NET enthalten sein.

Post by uwe Gutsche
Dann besser gleich in der .NET-App (die ist auch
schon ein Stück weiter verbessert)

Für Fragen in dieser Richtung dann vielleicht besser
in einem anderen Forum fragen ...
microsoft.public.de.german.entwickler.dotnet.vb
ist z.B. noch aktiv - ansonsten in den .NET-WebForen
auf dem MS-Webserver nachfragen.

[DB-Abstraktion per DAO(ODBC)]

Post by uwe Gutsche
Dadurch brauche ich keine Änderungen in den Abfragen
machen und die Verwendung/Auswertung der Daten
funktioniert in beiden Umgebungen.
Geht das dann bei ADO auch?

Aber sicher doch - das ist der Sinn eines solchen DB-
Zugriffslayers - wenn Deine Abfragen keine "großartigen
Spezialitäten" von der DB-Engine verlangen, dann wird
sich das Ganze nur auf das Ändern des jeweiligen Connect-
Strings beschränken.

Post by uwe Gutsche
Der zweite Teil (Daten suchen und lesen) funktioniert dann
übers Intranet von jedem Arbeitsplatz aus also als .htm/-asp -
Anwendung.
Wenn ich jetzt das Speichern auf .NET umstelle, kann doch
(vorerst) das Lesen im "klassischen" Stiel bleiben, denke ich.

Mir erschließt sich nicht ganz, wie Deine Anwendung
strukturiert ist - innerhalb von .asp würde ich jedenfalls
mit ADO arbeiten.

Post by uwe Gutsche
Es wäre schön, wenn Du ein (-ige) Musterbeispiel(e) hast und
dazu notwendige Informationen z.B. muss ich irgendwelche
Treiber, Programme... dafür installieren?

ADO kommt überall vorinstalliert (auf Systemen >= W2K) -
was manchmal nachinstalliert werden muss, sind bestimmte
OleDB-Driver für die jeweilige DB-engine. Im Falle von
JET und dem SQLServer sind aber auch hier die OLEDB-
Driver nahezu immer relativ aktuell (jedenfalls bei JET).

Es reicht also das Angeben einer MS ActiveX-DataObjects-
Referenz in Deinem VB6-Projekt.

Google einfach nach VB6+ADO+Recordset...
für VB.NET entsprechend nach ADO.NET+DataSet

Beispiele gibt es zur Genüge - und wie gesagt - hier in
der Gruppe eigentlich nur bei Problemen mit der Kombi
VB5/6+ADO nochmal nachfragen - ansonsten in einem
.NET-Forum.

Olaf

[uwe Gutsche]

Hallo Olaf,

Post by Schmidt
Da gibt es im Netz haufenweise Beispiele, wie man
mittels ADO Connections öffnet - und auf diesen
Connections dann ADO-Recordsets (inkl. Updates,
Manipulation, DataBinding dieser Container)
Schau z.B. mal auf der Seite von Peter Götz rein,
da sollten Beispiele sowohl für ADO+VB6 - als
auch für ADO.NET+VB.NET enthalten sein.

Habe ich gerade einige Beispiele gesammelt und denke, dass ich damit
klarkommen werde.

Post by Schmidt
Für Fragen in dieser Richtung dann vielleicht besser
in einem anderen Forum fragen ...
microsoft.public.de.german.entwickler.dotnet.vb
ist z.B. noch aktiv

nicht mehr, (letzter Eintrag: 27.12.10)

Post by Schmidt
- ansonsten in den .NET-WebForen
auf dem MS-Webserver nachfragen.

Mach ich, wenn nötig (hab ich inzwischen auch gefunden)

Post by Schmidt
Mir erschließt sich nicht ganz, wie Deine Anwendung
strukturiert ist - innerhalb von .asp würde ich jedenfalls
mit ADO arbeiten.

Ein Labor mit drei Computern (1*XP und 2*W-7) mit Mikroskopen und Kamera.
Die hier entstehenden Bilder werden (Teil 1) datenbankgestützt ins
Netzwerk "weggespeichert" (.exe).
(Teil 2) Sie können von jedem Platz im Intranetz über DB-Suche wieder
heruntergeladen und weiterbe/-verarbeitet werden (.asp).

Post by Schmidt
ADO kommt überall vorinstalliert (auf Systemen>= W2K) -
was manchmal nachinstalliert werden muss, sind bestimmte
OleDB-Driver für die jeweilige DB-engine. Im Falle von
JET und dem SQLServer sind aber auch hier die OLEDB-
Driver nahezu immer relativ aktuell (jedenfalls bei JET).
Es reicht also das Angeben einer MS ActiveX-DataObjects-
Referenz in Deinem VB6-Projekt.

??? das finde ich doch in den Beispielen, oder?

Post by Schmidt
Google einfach nach VB6+ADO+Recordset...
für VB.NET entsprechend nach ADO.NET+DataSet
Beispiele gibt es zur Genüge - und wie gesagt - hier in
der Gruppe eigentlich nur bei Problemen mit der Kombi
VB5/6+ADO nochmal nachfragen - ansonsten in einem
.NET-Forum.
Olaf

Nochmals besten Dank (Schlüsselwort für mich war wohl: "ADO") und
Grüße aus Dresden
Uwe

[W. Wolf]

Post by uwe Gutsche
Hallo an Alle,

[...]

Post by uwe Gutsche
Ich probiere jetzt schon seit einigen Wochen, komme aber immer an der
gleichen Stelle nicht weiter.
Ich vermute, dass es am 64Bit-System liegt, weil es unter XP ja geht.
Hat irgend jemand eine hilfreiche Idee?

Entschuldige die späte Antwort, die Idee kommt mir
erst jetzt wo Olaf sagt dass niemand mehr mit VB6
und DAO arbeitet. Außer in Galien, da gibt es noch ein
kleines Dorf... ;-)
Nein im Ernst: Ich programmiere hier mit DAO gegen
eine Ingres DB, allerdings unter 32 Bit. Bevor Du nun alles
in deinen Anwendungen auf den Kopf stellst, versuche mal
folgendes: besorge dir mal ein Programm wie EnumModules
(http://www.fantastic-bits.de/). Dieses listet dir unter XP dann
alle verwendeten DLLs bei laufendem Programm auf.
Auch unter 64-Bit werden später nur die 32-Bit DLLs zum
Einsatz kommen, folglich kannst damit ja schon mal feststellen
ob dir rein physikalisch was fehlt. Denke daran alle Funktionen
in der XP-Funktion aufgerufen zu haben, damit auch alle DLLs
geladen werden.

Zu DAO: es gibt diverse Installationspakete welche DAO mit
allen nötigen Bibliotheken installieren und einrichten. Wenn du willst,
kann ich dir davon was mailen - im Internet wirst Du sicher auch
was finden. Ich habe damit bisher noch jeden Rechner zur
Zusammenarbeit mit DAO bewegen können. Kann mir nicht
vorstellen, dass die 64 Bit am Nichtfunktionieren schuld sind,
kann's natürlich auch nicht ausschließen.

Schönen Gruß
W. Wolf

[uwe Gutsche]

Hallo W. Wolf,

Post by W. Wolf
besorge dir mal ein Programm wie EnumModules
(http://www.fantastic-bits.de/).

hab ich gerade geholt und probiere es morgen (nein doch heute) gleich aus.

Post by W. Wolf
Zu DAO: es gibt diverse Installationspakete welche DAO mit
allen nötigen Bibliotheken installieren und einrichten. Wenn du willst,
kann ich dir davon was mailen - im Internet wirst Du sicher auch
was finden. Ich habe damit bisher noch jeden Rechner zur
Zusammenarbeit mit DAO bewegen können.

würde ich mir mal für den "Notfall" offen halten (aber irgendwann muss
ich doch mal auf "das Neue" umsteigen).

Post by W. Wolf
Kann mir nicht vorstellen, dass die 64 Bit am Nichtfunktionieren schuld sind,
kann's natürlich auch nicht ausschließen.

Wenn es nicht notwendig ist, würde ich es auch nicht weiter untersuchen
wollen,
aber dieser Text (ist VB-6):

If InStr(sDbkMa, ".mdb") > 0 Then
Set dbkMa = OpenDatabase(sDbkMa)
ElseIf InStr(sDbkMa, "DSN") > 0 Then
Set dbkMa = wrkODBC.OpenDatabase("MaDSN", dbDriverNoPrompt, ,
"ODBC;Database=dbName;UID=uID;PWD=pWD;DSN=dSN")
End If
rstMa = dbkMa.OpenRecordset("SELECT Ma_Name, Ma_Vorname FROM
Mitarbeiter WHERE ......)

funktioniert bei XP (32Bit) sowohl ".mdb" als auch "DSN" und
auf W-7 (64Bit) aber nur ".mdb" und "DSN" nicht.

Ich denke, dass ich jetzt (auch mit den Hinweisen von Olaf) zu einem
vernünftigen Ergebnis kommen werde und danke Dir

beste Grüße
Uwe

[Wilfried Dietrich]

Post by W. Wolf
Zu DAO: es gibt diverse Installationspakete welche DAO mit
allen nötigen Bibliotheken installieren und einrichten. Wenn du willst,
kann ich dir davon was mailen - im Internet wirst Du sicher auch
was finden. Ich habe damit bisher noch jeden Rechner zur
Zusammenarbeit mit DAO bewegen können.

Ich will - davon was gemailt haben!

Gruß
Wilfried

Post by W. Wolf
post "at" widisoft.de <

[W. Wolf]

Post by Wilfried Dietrich

Post by W. Wolf
Zu DAO: es gibt diverse Installationspakete welche DAO mit
allen nötigen Bibliotheken installieren und einrichten. Wenn du willst,
kann ich dir davon was mailen - im Internet wirst Du sicher auch
was finden. Ich habe damit bisher noch jeden Rechner zur
Zusammenarbeit mit DAO bewegen können.

Ich will - davon was gemailt haben!
Gruß
Wilfried

Post by W. Wolf
post "at" widisoft.de <

7 MB sind unterwegs

Schönen Gruß
W. Wolf

[Wilfried Dietrich]

Post by W. Wolf
7 MB sind unterwegs

Erhalten.

Danke und schönen Gruß
Wilfried

[uwe Gutsche]

Post by W. Wolf

Post by Wilfried Dietrich
Ich will - davon was gemailt haben!

7 MB sind unterwegs

Davon würde ich jetzt auch eine "Kelle voll" nehmen. Olafs Tip: "Peter
Götz" hat alles für .NET2005 (geht unter 2003 erst gar nicht zu öffnen),
und die Module-Auflistung hab ich noch nicht fertig durchgearbeitet.


Mailto: uwe-***@online.de


Gruß
Uwe

[W. Wolf]

"uwe Gutsche" <***@tu-dresden.de> schrieb
[...]

Post by uwe Gutsche
Davon würde ich jetzt auch eine "Kelle voll" nehmen.

Ok, Postfach auf 7MB-Mail prüfen.

Schöne Grüße
W. Wolf

[uwe Gutsche]

Post by W. Wolf

Post by uwe Gutsche
Davon würde ich jetzt auch eine "Kelle voll" nehmen.

Ok, Postfach auf 7MB-Mail prüfen.

Hallo Wolfgang,

habe die Dateien "DAO(2)" entpackt, da sie sich auf W-7 (64) nicht
installieren ließen; Fehlertext:
"Die Version dieser Datei ist nicht mit der ausgeführten Windows-Version
kompatibel. Öffnen Sie die Systeminformation... ob eine x86(32 Bit)-
oder ... erforderlich ist, und wenden Sie sich..."

Dann habe ich Deine Dateien mit denen von W-7
("System\Programme(x86)\CommenFiles\microsoft shared\DAO") verglichen;
Unterschiede:

1) "DeIsL1.isu" existiert bei W-7 nicht.
2) DAO350.DLL Bei W-7 Version 3.51.1698.0 Datum 27.04.1998
3) DAO360.DLL Bei W-7 Version 3.60.0756.0 Datum 14.07.2009

Ich brauche ja nur die 3.60er -dll, oder?
und wozu ist die .isu da ?

Das Austauschen der Dateien führt
beim Öffnen von .mdb-Dateien zu Fehler 13 (Die angegebene Umwandlung ist
ungültig) und
beim Öffnen der DSN zu Fehler 3146 (ODBC-Aufruf fehlgeschlagen).

Der "Gut/Schlecht-Status" ist im Moment folgender:
(ich kann hier keine Tabelle einfügen, deshalb "Tab's")

kompiliert installiert Zugriff Funktion/
unter: auf; auf: Fehler:
---------------------------------------------------------------------
VB-6 XP .mdb iO
DSN iO
---------------------------------------------------------------------
W-7 (32) .mdb iO
DSN iO
---------------------------------------------------------------------
W-7 (64) .mdb iO
DSN 3146 (ODBC-Aufruf
fehlgeschlagen)
_____________________________________________________________________
.NET 2003 XP .mdb iO
DSN iO
---------------------------------------------------------------------
W-7 (32) .mdb iO
DSN iO
---------------------------------------------------------------------
W-7 (64) .mdb 13 (Die angegebene
Umwandlung ist
ungültig)
DSN 3146 (ODBC-Aufruf
fehlgeschlagen)

Was ich jetzt noch nicht getestet habe, ist XP(64), dazu ist der Aufwand
etwas größer.
ich sehe noch mal, nach EnumModules und melde mich mit dem Ergebnis.
Ich könnte aber auch noch die Entwicklungsumgebung(en) auf das W-7(64)
bringen (bis jetzt alles auf PX entwickelt) und dort kompilieren?

bis später
Uwe

[W. Wolf]

"uwe Gutsche" <***@tu-dresden.de> schrieb

[...]

Post by uwe Gutsche
_____________________________________________________________________
.NET 2003 XP .mdb iO
DSN iO
---------------------------------------------------------------------

Das dürfte in einer VB-Classic mit DAO
Umgebung kaum von Bedeutung sein. Oder
verwendest Du hier ein .Net-VB mit DAO?

[...]

Post by uwe Gutsche
---------------------------------------------------------------------
W-7 (64) .mdb 13 (Die angegebene
Umwandlung ist
ungültig)
DSN 3146 (ODBC-Aufruf
fehlgeschlagen)

Schon mal

If Err then
MsgBox dbengine.Errors(0).Description
end if

getestet?

Schönen Gruß
W. Wolf

[uwe Gutsche]

Post by W. Wolf

Post by uwe Gutsche
_____________________________________________________________________
.NET 2003 XP .mdb iO
DSN iO
---------------------------------------------------------------------

Das dürfte in einer VB-Classic mit DAO
Umgebung kaum von Bedeutung sein.

lässt aber möglicherweise Schlüsse zu, ob der Fehler im Quelltext oder
in fehlender "Umgebung" (DLLs...) liegt.

Oder

Post by W. Wolf
verwendest Du hier ein .Net-VB mit DAO?

der Quelltext ist inzwischen (zumindest an dieser Stelle) identisch, so
dass ich mit beiden Kompilern testen kann (VB-6 + VB-NET 2003)

Post by W. Wolf
Schon mal
If Err then
MsgBox dbengine.Errors(0).Description
end if
getestet?

die Fehlermeldung entsteht durch diese Zeilen (VB-6):

On Error GoTo Err_
If InStr(LCase(sDbkMa), ".mdb") > 0 Then
Set dbkMa = OpenDatabase(sDbkMa)
ElseIf UCase(sDbkMa) = "INVDSN" Then
Set dbkMa = wrkODBC.OpenDatabase("MaDSN", dbDriverNoPrompt, ,
"ODBC;Database=dbName;UID=uID;PWD=pWD;
End If
Err_:
MsgBox "Fehler " & Err.Number & " (" & Err.Description & ")",
vbApplicationModal + vbExclamation

in VB-NET sind eben die "Set"'s weggelassen.

Im Anhang schicke ich mal die Auflistung der Module mit.
(Geht leider nicht, weil ich kein "-binary" anhängen kann. Also wieder
als "Text")
Interessant sind wohl die, die bei XP geladen werden und bei W-7 nicht.
Nur werden z.B. die ganzen "Socket" -dll's (vermutlich) gar nicht erst
aufgerufen, da der ODBC-Fehler das Aufbauen der Netzwerkverbindung
verhindert.
Wie bekomme ich nun raus, welches die "erste" Fehlerursache ist??

Hier nun die Tabelle
(ich könnte vielleicht einige Zeilen ausschließen, aber das ist nicht
mehr mein Fachgebiet)

XP W-7 (64) Bemerkung

actxprxy
ADVAPI32 ADVAPI32
appHelp apphelp
ATL ATL Module for Windows XP (Unicode)
ATL80 ATL Module for Windows (Unicode)
browseui Shell Browser UI-Bibliothek
bcrypt
bcryptprimitives
CFGMGR32 CFGMGR32
CLBCATQ CLBCatQ
COMCTL32 comctl32
comctl32 COMCTL32
comdlg32 comdlg32
COMDLG32 COMDLG32.OCX
COMres (null)
CRYPT32 CRYPT32
CRYPTBASE
CRYPTSP
cryptdll Cryptography Manager
CRYPTUI Microsoft Vertrauens-UI-Anbieter
cscapi
DAO360 dao360
davcInt davclnt
DAVHLPR
DBNETLIB Winsock Oriented Net DLL for SQL Clients
DEVOBJ
DNSAPI DNS Client API DLL
drprov drprov
dssenh Microsoft Enhanced DSS and Diffie-
Hellman Cryptographic Provider
DUI70
DUser
dwmapi
EhStorAPI
EhStorShell
explorerframe
expsrv expsrv
FwcWsp Microsoft Firewall Client Windows
Sockets 2 Service Provider
GDI32 GDI32
GrooveNew GrooveNew Module
GrooveShellExtension GrooveShellExtensions Module
GrooveSystemServices GrooveSystemServices Module
GrooveUtil GrooveUtil Module
hnetcfg Heimnetzwerkkonfigurations-Manager
ieframe
ieproxy
iertutil iertutil
IMAGEHLP Windows NT Image Helper
IMM32 IMM32
iphlpali IP-Hilfs-API
kernel32 kernel32
KERNELBASE
LINKINFO
LPK LPK
MPR MPR
MSASN1 MSASN1
MSCTF MSCTF
msctfime.ime Microsoft Text Frame Work Service IME
msi msi
msiltcfg
MSImg32 GDIEXT Client DLL
MSJET40 MSJET40
MSJINT40
MSJTER40
msjtes40 msjtes40
msls31
MSRDO20 MSRDO20
msv1_0 Microsoft Authentication Package v1.0
MSVBVM60 MSVBVM60
MSVCR80 Microsoft® C Runtime Library
msvcrt msvcrt
mswsock Microsoft Windows Sockets
2.0-Dienstanbieter
mswstr10 mswstr10
msxml3 MSXML 3.0 SP10
NDDEAPI Netzwerk-DDE Share Management-APIs
NETAPI32 Net Win32 API DLL
NETRAP Net Remote Admin Protocol DLL
NETUI0 NT-LM-Benutzerschnittstellen-
Standardcode - GUI-Klassen
NETUI1 NT LM UI Common Code - Networking
classes
netutils
NetworkExplorer
Normaliz Unicode Normalization DLL
ntdll ntdll
ntdsapi NT5DS
ntlanman ntlanman
ntmarta
ntshrui ntshrui
nvLsp NVIDIA IAM LSP
ODBC32 ODBC32
odbccp32 Microsoft Data Access - ODBC Installer
odbcint odbcint
ole32 ole32
OLEACC
OLEAUT32 OLEAUT32
PortableDeviceApi PortableDeviceApi
profapi
propsys
PSAPI PSAPI
rasadhlp Remote Access AutoDial Helper
Rdo20DE Rdo20DE
RPCRT4 RPCRT4
RpcRtRemote
rsaenh rsaenh
SAMLIB SAM Library DLL
schannel TLS / SSL Security Provider
SearchFolder
sechost
Secur32 Secur32
security Security Support Provider Interface
SETUPAPI SETUPAPI
SFC
sfc_os
SHDOCVW SHDOCVW
SHELL32 SHELL32
SHLWAPI SHLWAPI
slc
sqlsrv32 Microsoft SQL Server ODBC Driver
sqlsrv32.rll Microsoft SQL Server ODBC-Treiber
SQLUNIRL String Function .DLL for SQL Enterprise
Components
srvcli
SspiCli
sti Digitalbildgeräte-Client-DLL
StructuredQuery
SXS SXS
thumbcache
tiptsf
urlmon urlmon
USER32 USER32
USERENV Userenv
USP10 USP10
UXTHEME uxtheme
VB6DE VB6DE
VBAJET32 VBAJET32
VERSION VERSION
WindowsCodecs
WINMM
WININET Internet Extensions for Win32
winrnr LDAP RnR Provider DLL
WINSTA
WINSPOOL Windows-Spoolertreiber
WINTRUST WINTRUST
wkscli
WLDAP32 WLDAP32
WS2_32 Windows Socket 2.0 32-Bit DLL
WS2HELP Windows Socket 2.0 Helper für Windows NT
wshtcpip Windows Sockets Helper DLL
WSOCK32 Windows Socket-32-Bit-DLL
xmllite
xpsp2res Service Pack 2-Meldungen





Grüße
Uwe

[W. Wolf]

Post by uwe Gutsche

Post by W. Wolf
If Err then
MsgBox dbengine.Errors(0).Description
end if
getestet?

On Error GoTo Err_
If InStr(LCase(sDbkMa), ".mdb") > 0 Then
Set dbkMa = OpenDatabase(sDbkMa)
ElseIf UCase(sDbkMa) = "INVDSN" Then
Set dbkMa = wrkODBC.OpenDatabase("MaDSN", dbDriverNoPrompt, , "ODBC;Database=dbName;UID=uID;PWD=pWD;
End If
MsgBox "Fehler " & Err.Number & " (" & Err.Description & ")", vbApplicationModal + vbExclamation

Damit prüfst Du aber nicht die dbengine.Errors(0).Description
Gerade beim Fehler 3146 könntest Du Relevantes in
der Description des DBEngine-Error-Objektes erfahren.
Beachte:
Err.Description ist nicht dbengine.Errors(0).Description

Bei der DLL-Liste kann ich nicht weiterhelfen,
ich verwende ja nicht MS-SQL, also habe ich
andere ODBC-Treiber. Mit dieser Liste kannst
Du Vergleiche mit funktionierenden Systemen
machen um zu sehen ob hier DLLs verwendet
werden welch auf deinem fehlerhaften System
gar nicht vorhanden/installiert sind.

Schönen Gruß
W. Wolf

[uwe Gutsche]

Post by W. Wolf
Damit prüfst Du aber nicht die dbengine.Errors(0).Description
Gerade beim Fehler 3146 könntest Du Relevantes in
der Description des DBEngine-Error-Objektes erfahren.
Err.Description ist nicht dbengine.Errors(0).Description

leuchtet mir ein (jetzt...)

Post by W. Wolf
Bei der DLL-Liste kann ich nicht weiterhelfen,
ich verwende ja nicht MS-SQL, also habe ich
andere ODBC-Treiber. Mit dieser Liste kannst
Du Vergleiche mit funktionierenden Systemen
machen um zu sehen ob hier DLLs verwendet
werden welch auf deinem fehlerhaften System
gar nicht vorhanden/installiert sind.

gut.., wenn ich ein (anderes) System zum Vergleichen habe.
Jetzt geht inzwischen alles (auch das .NET), aber nun brauche ich es ja
nicht mehr vergleichen :-), beim nächsten Mal denke ich wieder dran.

nochmal besten Dank
Uwe

[Lutz Uhlmann]

Post by W. Wolf
Zu DAO: es gibt diverse Installationspakete welche DAO mit
allen nötigen Bibliotheken installieren und einrichten. Wenn du willst,
kann ich dir davon was mailen - im Internet wirst Du sicher auch
was finden. Ich habe damit bisher noch jeden Rechner zur
Zusammenarbeit mit DAO bewegen können. Kann mir nicht
vorstellen, dass die 64 Bit am Nichtfunktionieren schuld sind,
kann's natürlich auch nicht ausschließen.

Ich hab in solchen Fällen immer die MDAC-Pakete benutzt, die man bei MS
runterladen kann ...
Die enthalten meines Wissens nach auch DAO!

Weiß bloß nicht genau wie das für Vista oder Win7 funktioniert.

[Lutz Uhlmann]

Post by Lutz Uhlmann
Ich hab in solchen Fällen immer die MDAC-Pakete benutzt, die man bei MS
runterladen kann ...
Die enthalten meines Wissens nach auch DAO!
Weiß bloß nicht genau wie das für Vista oder Win7 funktioniert.

Tun sie offensichtlich nicht. Mein DAO kam wohl über das Office-Paket
und MDAC deckte nur den ODBC-Teil ab - war schon länger her.

Eine schöne Übersicht gibts hier:
http://msdn.microsoft.com/en-us/library/ms810810.aspx

[uwe Gutsche]

Post by Lutz Uhlmann
http://msdn.microsoft.com/en-us/library/ms810810.aspx

Stimmt,
inzwischen geht bei mir alles (auch unter .NET),

nochmals besten Dank
Uwe

[Lutz Uhlmann]

Hast du die richtige ODBC-Datenquelle angelegt???

Den ODBC-Datenquellen-Administrator gibt es meines Wissens nach in zwei
Versionen 32bit und 64bit.

Unter Vista ist der 64bit unter
%SystemRoot%\system32\odbcad32.exe
zu finden (Standardaufruf)
Der 32bit versteckt sich dagegen unter
%SystemRoot%\SysWOW64\odbcad32.exe

Jetzt kommt es drauf an mit welchem Bit-System du arbeitest und unter
welchem du deinen DSN angelegt hast.
Wenn ich mit einem 32bit Programm arbeite nutzt mir der unter 64bit
(Standard) angelegte DSN nichts sondern ich muß einen unter 32bit anlegen.

Vielleicht ist das ja nur dein Problem?

[uwe Gutsche]

Post by Lutz Uhlmann
Hast du die richtige ODBC-Datenquelle angelegt???
Den ODBC-Datenquellen-Administrator gibt es meines Wissens nach in zwei
Versionen 32bit und 64bit.
Unter Vista ist der 64bit unter
%SystemRoot%\system32\odbcad32.exe
zu finden (Standardaufruf)
Der 32bit versteckt sich dagegen unter
%SystemRoot%\SysWOW64\odbcad32.exe
Jetzt kommt es drauf an mit welchem Bit-System du arbeitest und unter
welchem du deinen DSN angelegt hast.
Wenn ich mit einem 32bit Programm arbeite nutzt mir der unter 64bit
(Standard) angelegte DSN nichts sondern ich muß einen unter 32bit anlegen.
Vielleicht ist das ja nur dein Problem?

Ein Lichtblick am Horizont!

Ich hatte natürlich über "Systemsteuerung\Verwaltung\Datenquellen(ODBC)"
meine DSN eingerichtet (Standard=64 Bit). Mit deinem Tipp habe ich die
Datenquelle in 32 Bit eingerichtet (gestern Abend) und nichts hatte sich
gebessert. Nachts viel mir dann ein, den DSN-Eintrag unter 64 Bit zu
löschen - und siehe da, VB-6 Programm geht auch unter W-7 (64 Bit).
(Jetzt muss ich das ganze noch für .NET hinbekommen, aber das mache ich
mit Hilfe einer anderen NG).

Besten Dank noch Mal Lutz, aber auch an Wolfgang und Olaf
Viele Grüße aus Dresden
Uwe