|
| |
VB & Datenbanken| DB-Nutzung unter Windows 10 | |  | | Autor: Rainer | | Datum: 30.12.16 11:31 |
| Hallo,
ich habe folgendes Problem:
Unter WinXP habe ich ein Programm geschrieben, das mit Hilfe von Data-Steuerelemente auf eine Datenbank zugreift. Alle diese Steuerelemente sind mit der Eigenschaft Connect="ACCESS 2000;" eingestellt und laufen unter WinXP und Win7 ohne Probleme mit dem Verweis auf DAO360.DLL und seine zugehörigen Komponenten.
Bei der Installation des Programms unter Win10 verlangen diese Steuerelemente aus mir unerkärlichen Gründen plötzlich die DAO350.DLL für den Zugriff auf die Datenbank. Was die Sache für mich noch undurchschaubarer macht, ist die Tatsache, daß unter Win7 - wie unter Win10 - nur die DAO360.DLL installiert vorliegt und das Programm dort problemlos läuft.
Hat jemand eine Idee, woran dieses veränderte Verhalten unter Win10 liegen kann?
Gruß, Rainer. | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: Rainer | | Datum: 02.01.17 14:45 |
| Ergänzung:
Versuchsweise habe ich das Programm in einem Win10 (32Bit-BS auf x64-basierten Prozessor) installiert. Auch dort mußte ich DAO350 mit seinen zusätzlichen Komponenten (siehe "vb@rchiv-FAQ-Programm weitergeben") nachinstallieren. Dann ist es allerdings einwandfrei gelaufen.
Die o.g. problematische Installation erfolgte in einem Win10 (64Bit-BS). Der einzige Unterschied, der m.E. bei beiden Installationen eine Rolle spielen kann, ist, daß die zur DAO350.DLL gehörenden DLL-Dateien in einem anderen Verzeichnis - SYSWOW64 statt SYTEM32 - zu finden sind. Eine Überprüfung der Verweise in der Registry für die Dateien MSRD2X35.DLL, MSRD2X40.DLL und MSRD3X40.DLL, die für die ISAM-Arbeit zuständig sind, ergab keine Abweichungen. D.h., alle Verweise der Registry auf diese Dateien beziehen sich auf den SYSWOW64-Ordner.
Hat jemand vielleicht eine Idee, welche DLL-Datei außer denen, die in dem FAQ genannt werden, fehlen könnte? Oder gibt es noch einen Ort an dem mit Verweisen auf diese Dateien gearbeitet wird?
Rainer. | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: Oggi | | Datum: 02.01.17 16:25 |
| Howdy Rainer,
c:\Programme\Gemeinsame Dateien\Microsoft Shared\dao\Dao350.dll
c:\windows\system\expsrv.dll
c:\windows\system\msjet35.dll
c:\windows\system\msjint35.dll
c:\windows\system\msjter35.dll
c:\windows\system\msrd2x35.dll
c:\windows\system\msrepl35.dll
c:\windows\system\msvcrt40.dll
c:\windows\system\vbajet32.dll
c:\windows\system\Vb5db.dll
Als Registrierhilfe biete ich die Freeware "OCX-Reg" an.
https://www.oggisoft.de/ocx.htm
Alternativ kannst du meine Shareware "Schallarchiv" im Adminkonto kurz installieren und deinstallieren. Das Setup meldet dabei die obigen Dateien im System an.
https://www.oggisoft.de/schallarchiv.htm
beste Neujahrsgrüße
Oggi | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: Oggi | | Datum: 02.01.17 17:01 |
| Ups, ich meinte natürlich die Ordner ..\system32 bzw. unter Win10 ..\syswow64. Das Setup kennt den Weg  | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: Rainer | | Datum: 02.01.17 17:27 |
| Hallo Oggi,
Dir auch alles Gute zum neuen Jahr und Dank für Deine Antwort.
Die von Dir aufgelisteten Dateien sind auf dem Zielrechner alle bereits vorhanden und - wenn notwendig - auch registriert.
Eine Sache ist mir bei der Kontrolle noch aufgefallen: ein Teil der DLL-Dateien war mit der Systeminstallation schon vorhanden. Die fehlenden Dateien habe ich aus meinem XP-System übernommen. Eine möglich Ursache kann also sein, daß die alten DLL-Dateien unter dem x64-BS mit den vorhandenen DLL's nicht sauber korrespondieren. Wenn dem so ist, erhebt sich die Frage woher ich die unter Win10 ablauffähigen DLL's bekomme. Kennst Du vielleicht eine verläßliche Quelle?
Gruß, Rainer. | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: Oggi | | Datum: 02.01.17 17:53 |
| | Nein, kenn ich nicht. Die XP-Dateien auch mal in den Programmordner kopieren, dort sucht Win immer als Erstes. Der Trick hat schon oft geholfen. | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: Rainer | | Datum: 02.01.17 18:29 |
| Danke, das wars leider nicht.
Rainer | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: Rainer | | Datum: 02.01.17 19:01 |
| 2. Ergänzung:
Habe mit dem Tool DEPENDENCY WALKER 2.2.6000 für Win64 (x64) mal die DLL-Abhängigkeiten ermitteln lassen. Dabei habe ich festgestellt, daß DAO350.DLL die MSVCLT40.DLL, die offensichtlich die verbindende DLL zu den anderen DLLs darstellt, im Systemordner SYSTEM32 sucht und nicht findet. Auch die anderen von DAO350.DLL zusätzlich verwendeten DLL KERNEL32, USER32,ADVAPI32, OLE32 und OLEAUT32 werden in SYSTEM32 verwendet.
Somit löst sich scheinbar das Problem mit der Klärung der Frage: Wie kann ich DAO350.DLL veranlassen als Systemordner den Ordner SYSWOW64 zu verwenden?
Ich wäre Euch sehr dankbar, wenn mir einer weiterhelfen könnte.
Gruß, Rainer. | |
Re: es ist leider alles nicht so wie es scheint - Microsoft sei Dank  | | | | Autor: visualfx | | Datum: 03.01.17 01:03 |
| Hallo Rainer,
- ich würde zunächst mal erforschen, warum Dein Programm, Deine Komponenten unter Windows 10 nicht die DAO360 sondern die DAO350 verwenden möchte.
- ein Nachinstallieren der DAO350 macht für mich da absolut keinen Sinn! Damit beseitigst Du nur das Symptom, aber nicht die Ursache! 
1) Du kannst ja mal die dao360.dll im Dependency-Walker öffnen, da werden unterlagert auch scheinbar DLLs aus dem Ordner System32 verwendet - siehe hierzu noch weiter unten bei 3)!
2) Übrigens: alle "Dateien" im Ordner SysWow64 als auch im Ordner System32 sind nur Platzhalter / Stellvertreter, die richtigen Dateien befinden sich im Ordner C:\Windows\WinSxS, und zwar mehrfach in x Versionen !!!
Bei allen Datei-Operationen (neu anlegen, löschen, umbenennen, öffnen, schließen, lesen, schreiben, ausführen, etc.) werden die Platzhalter / Stellvertreter im Ordner SysWow64 und System32 mit den Dateien im Ordner WinSxS synchronisiert.
3) Hinzu kommt noch die 64 Bit File System Redirection (Redirection = Umleitung), die man z. B. mit Wow64EnableWow64FsRedirection ausschalten und auch wieder einschalten kann.
Unter Windows xyz 64 Bit ist die Redirection für 32 Bit-Programme standardmäßig eingeschaltet: das bewirkt, daß beim Laden einer System-DLL (z. B. Msvcrt.dll) immer die DLL aus dem SysWow64-Ordner geladen wird, selbst auch dann wenn man den Pfad angibt, also z. B. C:\Windows\System32\Msvcrt.dll - auch hier wird die Msvcrt.dll aus dem SysWow64-Ordner geladen !!!
Will man dagegen mit einem 32 Bit-Programm wirklich z. B. eine Datei aus dem System32-Ordner laden - oder eine Datei im System32-Ordner anlegen, etc., muß man vorher die Redirection ausschalten und nach dem Laden bzw. Anlegen, etc. unverzüglich wieder einschalten.
- daß Microsoft da selber noch nicht den Überblick verloren hat, ist mir ehrlich gesagt ein absolutes Rätsel . . .
Gruß, Stefan
Beitrag wurde zuletzt am 03.01.17 um 01:25:24 editiert. | |
| Re: es ist leider alles nicht so wie es scheint - Microsoft sei Dank | | | | Autor: Oggi | | Datum: 03.01.17 09:46 |
| Howdy Stefan,
dir auch alles Gute im neuen Jahr 2k17 und vielen Dank für deinen lehrreichen Beitrag! Den kann ich beim Support meiner Software sicher immer mal wieder gut und dankbar verwenden. Ich wurde damals noch unter Win NT 4 und Novell IntranetWare ausgebildet und das ist eben schon lange her.
Rainer sollte seine Software mal in einer virtuellen Maschine installieren. Mich würde interessieren ob das Prob. dort auch auftritt und vielleicht durch die bloße Installation einer unter Win 10 funktionierenden VB6 Anwendung mit Datenbankzugriff (z. B. meinem Schallarchiv s. o.) behoben werden kann.
Das Problem mit der DAO350.dll hatte ich noch zur Zeit von Win98/NT umschiffen müssen, das sieht man an den alten Pfaden die ich aus meinem Notizen-Manager ausgegraben habe. Ich bin da den einfachen Weg gegangen und habe die DAO350.dll eben mit ins Setup gepackt. | |
| Re: es ist leider alles nicht so wie es scheint - Microsoft sei Dank | | | | Autor: visualfx | | Datum: 03.01.17 11:56 |
| Hallo Oggi,
1) ich selbst verwende zwar kein Access / DAO, ich würde aber trotzdem jedem empfehlen die ältere DAO350 nicht mitzuinstallieren bzw. nachzuinstallieren.
Zumal DAO360 ja bereits vorinstalliert zu sein scheint. Auch auf meinem PC mit Windows 10 / 64 Bit gibt es DAO360. Access, etc. habe ich selbst aber nicht installiert.
Die neuste Version ist DAO360, eine neuere gibt es nicht. Wobei aber sogar Microsoft selbst empfiehlt DAO gar nicht mehr zu benutzen
DAO, siehe hier: https://de.wikipedia.org/wiki/Data_Access_Objects
D. h. leider aber auch andersherum: es gibt keine Gewähr, wie lange Microsoft DAO überhaupt noch unsterstützt!
2) Die 64 Bit File System Redirection ist übrigens der Grund, warum ein 32 Bit-Setup / eine 32Bit-Installation sich nicht um den richtigen System-Ordner kümmern muß.
Dateien werden immer in den SysWow64-Ordner installiert, selbst wenn man C:\Windows\System32 angibt
Gruß, Stefan
Beitrag wurde zuletzt am 03.01.17 um 11:58:47 editiert. | |
| Re: es ist leider alles nicht so wie es scheint - Microsoft sei Dank | | | | Autor: Rainer | | Datum: 03.01.17 12:14 |
| Hallo Stefan und Oggi,
vielen Dank für Eure Info. Wäre es mein PC, bei dem das Problem auftritt, hätte ich wahrscheinlich auch zu der Möglichkeit gegriffen eine virtuelle XP-Maschine einzurichten und unter deren Steuerung das Programm installiert. Ist es aber nicht. D.h., ich muß mit der vorliegenden Betriebssystem-Installation zurechtkommen. Außerdem würde auch dieses Herangehen nicht die Ursache des Problems (siehe Beitrag von Stefan) klären.
Es sind ja nun offensichtlich zwei Probleme zu lösen:
1.
Stefan, kritisiert mein Bemühen mit der Nachinstallation von DAO350.DLL zu Recht als Rumwerkeln an der Erscheinung ohne die Ursache zu beseitigen. Das war aber der Hintergrund meiner Ausgangsfragestellung. Ich habe keine andere Erklärung dafür, als daß es mit Windows 10 zusammenhängen muß. Denn auch die Installation auf einem Win10-PC mit nur 32Bit-System verlangt für die Verwendung des DATA-Controls die DAO350.DLL, nur daß dort die Nachinstallation zum gewünschten Ergebnis (auch keine Ursachenbeseitigung!) führt. Bei der Installation unter Win7 mit einem 64Bit-System (für Win8 und Win8.1 habe ich keine Erkenntnisse) tritt dieses Problem für das gleiche Programm nicht auf. Kann es also sein, daß Win10 eine andere DLL für die Bedienung des DATA-Controls mittels DAO360.DLL verlangt? Ich werde versuchen dies mit Hilfe des Dependency Walker zu klären.
2.
Die Information von Stefan über die Verfahrensweise bei der Trennung des 32Bit- von dem 64Bit-Dateisystems finde ich auch sehr interessant. Nur scheint mir die Aussage, daß es im Prinzip egal ist wo der DLL-Verweis abgelegt ist, nicht korrekt zu sein. Wenn das so wäre, hätte ich für das unterschiedliche Verhalten von Win10 (32Bit) und Win10 (64Bit) in Bezug auf die Nachinstallation von DAO350 keine plausible Erklärung. Zur Klärung werde ich versuchen, die DLL MSRD2X35, die für den ISAM-Datenzugriff verantwortlich ist, in den Ordner SYSTEM32 zu installieren. Ggf. werde ich dies auch mit dem gesamten DAO350-DLL-System versuchen.
Ich melde mich in jedem Fall noch mal. Seid bis dahin bedankt.
Rainer. | |
| Re: es ist leider alles nicht so wie es scheint - Microsoft sei Dank | | | | Autor: Rainer | | Datum: 03.01.17 12:37 |
| Hallo Stefan,
entschuldige, wenn ich mich in Deinen Dialog mit Oggi "einmische".
Aus heutiger Sicht, kann ich Dir nur Recht geben. Aber das Programm um das es hier geht wurde von mir 2004 unter XP fertiggestellt und seitdem auf diesem Systemlevel gewartet. Es ist also mehr oder weniger ein historisches Paket mit dem ich mich hier "herumschlage".
Rainer. | |
| Re: es ist leider alles nicht so wie es scheint - Microsoft sei Dank | | | | Autor: visualfx | | Datum: 03.01.17 12:49 |
| Hallo Rainer,
- ich stimme Dir zu, das Forschen nach der Ursache kann sich bei solchen Problemen zu einem Stochern im Heuhaufen auswachsen . . .
Aber noch ein Tipp: überprüfe doch mal, ob auf dem betroffenen Rechner von Windows 10 wirklich die neuste Version, also alle Windows-Updates installiert sind.
Gehe hierzu nach => Windows-Einstellungen => Update und Sicherheit
Unter Erweiterte Optionen kann man noch einstellen: Updates für andere Microsoft-Produkte bereitstellen, wenn Windows-Update ausgführt wird
Ob das für DAO nötig ist, weiß ich leider nicht.
Die neuste Windows 10-Version lautet: Version 1607 (Build 14393.567), starte hierzu winver.exe
- leider ist Windows 10 auch heute immer noch nicht so ausgereift, wie damals ein Windows XP mit SP3 von Ende 2006
Gruß, Stefan | |
| Re: es ist leider alles nicht so wie es scheint - Microsoft sei Dank | | | | Autor: visualfx | | Datum: 03.01.17 12:58 |
| Hallo Rainer,
- absolut kein Problem! "Einmischen" ist immer gut
- außerdem gibt es in einem Forum ja sowieso keine private bidirektionale Konversation, alles ist öffentlich: jeder darf jede Frage und jede Antwort posten
- es gibt eh niemanden der alles weiß, jeder profitiert von einem Forum
Gruß, Stefan | |
| Re: DAO350 ist Bestandteil von Win10 | | | | Autor: Oggi | | Datum: 03.01.17 14:41 |
| Howdy,
in einem frisch installierten Win10 64-bit sind nur im Ordner ..\SysWow64 enthalten:
DAO350.dll Vers. 3.51.1608.0, Dateigröße 556 KB, Sprache: english
DAO360.dll Vers. 3.60.3706.0, Dateigröße 544 KB, Sprache: sprachneutral
es müssen demnach die beiden von einander abhängigen (wie auch immer) DAO's auf dem OS vorhanden sein (Dateiliste s. o.). Bei Problemen, so meint das Internet, hilft die Systemreparatur von Win10. Evtl. die Installation vom Schallarchiv, zuvor aber die DAO350.dll mittels Regsrv32.exe deinstallieren und aus dem Ordner SysWow64 verbannen.
P.S.: Nicht vergessen, das Schallarchiv läuft problemlos unter Win10! | |
| Re: DAO350 ist Bestandteil von Win10 | | | | Autor: Rainer | | Datum: 03.01.17 15:52 |
| Hallo Oggi,
die DAO350 war nie Teil von SYSTEM32 bzw. SYSWOW64. Diese DLL-Datei ist schon seit XP-Zeiten Bestandteil des Ordners "C:\Program Files\Common Files\microsoft shared\DAO" bzw. "C:\Program Files (x86)\Common Files\microsoft shared\DAO". Das gilt auch für Win10. Dies ist auch der Ordner, auf den alle Verweise in der Registry auf die DAO360 hinweisen. Ich habe alle mir verfügbaren Systeme Win10 (32Bit), Win10 (64Bit) und Win7 (64Bit) dahingehend geprüft und festgestellt, daß in keinem dieser Systeme die DAO350.DLL und DAO360.DLL in den Ordnern SYSTEM32 oder SYSWOW64 vorhanden sind. Lediglich im - von Stefan erwähnten - Ordner C:\Windows\SYSWXW ist von der Systeminstallation her die DAO360 zu finden.
Gruß, Rainer | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: Rainer | | Datum: 03.01.17 17:24 |
| Hallo,
ich habe nun den Punkt 2 meiner Problemstellung realisiert und mußte feststellen, daß die Verlegung des DAO350-Dateisystems in den Ordner SYSTEM32 auf die Fehlermeldung 3170 keinerlei Auswirkung hatte. Für das Dependency Walker-Programm war nun die Verbindung zu den untergeordneten DLL-Dateien hergestellt, aber das wars auch schon.
Was den Update-Status und die BS-Version betrifft, sind die Hinweise von Stefan alle erfüllt.
Was bleibt, ist die Ausgangsfrage: Warum überhaupt das DATA-Control in Win10 den DB-Zugang über DAO350 verlangt, wenn die Control-Eigenschaft CONNECT mit "Access 2000;" eigentlich die Nutzung von DAO360 einschließt?
Wenn sich niemand findet, der diese Frage beantworten kann, muß ich passen.
Die Hoffnung stirbt zuletzt, heißt es. Na, dann...
Rainer. | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: visualfx | | Datum: 03.01.17 17:55 |
| Hallo Rainer,
welche Versionen haben eigentlich Deine DAO360.dlls ???
Und zwar:
- auf Deinem Entwicklungs-Rechner
- und auf Deinem Ziel-Rechner, der die Probleme bereitet
Gruß, Stefan | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: Rainer | | Datum: 03.01.17 18:39 |
| Hallo Stefan,
auf dem Entwicklungs-PC XP Vers. 3.60.9512.0
1. Nutzung Win7 3.60.9756.0
Problemnutzung Win10 3.60.9765.0
Warum fragst Du?
Gruß, Rainer. | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: visualfx | | Datum: 03.01.17 19:10 |
| Hallo Rainer,
die neuste Version der DAO360.dll ist 3.60.9765.0, also so wie auf dem Windows 10-Rechner.
Ich würde auch auf den Entwicklungs-Rechner diese Version kopieren und registrieren und dann Dein Programm nochmal komplett generieren.
Microsoft hat vor garnicht langer Zeit schon mal den Bock geschossen, daß bei der Mscomctl.ocx und der Mscomct2.ocx das Interface zwischen zwei verschiedenen Versionen nicht mehr kompatibel war !!!
Mscomctl.ocx Version 6.01.9816 auf dem Entwicklungs-Rechner, aber Version 6.01.9833 oder 6.01.9834 auf dem Ziel-Rechner - und nix ging mehr
- übrigens befindet sich bei mir die DAO360.dll auch im Ordner: C:\Program Files (x86)\Common Files\Microsoft Shared\DAO
- ind diesem Ordner befindet sich auch nur die DAO360.dll und sonst nix
- in der Registry lauten die Verweise jeweils: %CommonProgramFiles%\Microsoft Shared\DAO\dao360.dll
Gruß, Stefan | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: Rainer | | Datum: 03.01.17 20:13 |
| Hallo Stefan,
die Idee hat was für sich. Ich werde es ausprobieren.
Bis dahin.
Gruß, Rainer | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: visualfx | | Datum: 03.01.17 20:34 |
| noch ein kleiner Nachtrag:
- ich entwickle hauptsächlich mit Visual Foxpro von Microsoft. Die Dao360.dll habe ich zwar noch nicht verwendet, aber ca. 30 verschiedene OCXe / ActiveX-Controls von allen möglichen Herstellern.
Da muß ich immer das Control per Drag and Drop auf das jeweilige Formular ziehen.
- wenn das bei VB6 und der Dao360.dll genauso ist, würde ich zuerst mal nach dem Installieren und Registrieren der neusten Dao360-Version das alte Control von der Form löschen und dann das neue Control wieder draufziehen. VB6 muß auf jeden Fall das Interface vom neuen Control / von der neuen Version instanzieren!
Dann erst die Anwendung komplett neu generieren.
Good luck, Stefan | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: Rippler | | Datum: 03.01.17 22:31 |
| Ich hatte als ich noch mit DAO gearbeitet hatte auch
dasselbe Problem mit den verschiedenen Versionen.
Mit später Bindung war es dann erledigt. | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: visualfx | | Datum: 03.01.17 23:02 |
| Hallo Rippler, hallo Rainer,
OK, sehr guter Hinweis, das leuchtet mir ein !!!
- bei der frühen / early Bindung wird das Interface vom Control auf dem Entwicklungs-Rechner während der Entwurfszeit instanziert!
- bei der späten / late Bindung wird das Interface vom Control auf dem Ziel-Rechner während der Laufzeit instanziert!
Erklärung von Microsoft siehe auch hier: https://support.microsoft.com/de-de/kb/245115
Ich würde jetzt mal ganz stark vermuten: ein Instanzieren der Schnittstelle per Drag and Drop des Controls auf ein Formular entspricht natürlich auch der frühen / early Bindung.
Gruß, Stefan
Beitrag wurde zuletzt am 03.01.17 um 23:06:35 editiert. | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: Rainer | | Datum: 04.01.17 13:46 |
| Hallo Stefan, hallo Rippler,
die Umstellung des DATA-Controls von der frühen auf die späte Bindung erscheint mir als die akzeptablere und logischere Variante. Noch dazu, weil ich doch ziemliche Bedenken habe mir meine einzige noch verbliebene VB6-Entwicklungsumgebung mit der Übernahme der DAO360.DLL aus Win10 womöglich zu "zerschießen".
Nun gibt es für mich aber noch ein Problem: meine IT-Ausbildung liegt denn doch schon einige Zeit zurück, sodaß ich zwar den Microsoft-Artikel vom Wesen her verstanden habe, aber ich mit der konkreten Umsetzung in meinem Projekt (VB6-IDE) so meine Schwierigkeiten habe. Ich bräuchte also konkretere Hilfe.
Dazu einige Bemerkungen zum Projekt:
Es handelt sich um ein ziemlich umfangreiches Projekt mit einer ziemlich großen Anzahl von Formularen, die als MDI-Formulare an des Hauptformular gebunden sind. Die infrage kommenden DATA-Controls wurden aus der ToolBox der IDE mittels Drag & Drop übernommen und verwendet. Die zum Fehler 3170 führende Stelle lautet:
870 Me.datTbsNT.RecordsetType = vbRSTypeDynaset ' Tabellenzuweisung
880 Me.datTbsNT.DatabaseName = goDbBas.Name
890 Me.datTbsNT.RecordSource = "SELECT * FROM Textbausteine ORDER BY" & _
"TBname; "
900 Me.datTbsNT.Refresh "datTbsNT" ist der Name des DATA-Controls, bei dem die Eigenschaft CONNECT auf "Access 2000;" gesetzt ist. "goDbBas" ist das DB-Objekt, das die dem DATA-Control zuzuordnende Tabelle "Textbausteine" enthält. Die Anforderung der DAO350.DLL wie auch der anschließend auftretene Fehler 3170 erfolgten immer beim Refresh in Zeile 900.
Wie muß ich vorgehen, um das DATA-Control von der frühen auf die späte Bindung umzustellen und damit die Nutzung der in Win10 enthaltenen DAO360 zu verwenden?
Ich wäre Euch sehr verbunden, wenn Ihr mich nicht dumm sterben laßt.
Gruß, Rainer. | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: visualfx | | Datum: 04.01.17 21:32 |
| Hallo Rainer,
1) Frühe Bindung:
- entweder das Control per Drag & Drop auf das Formular ziehen = frühe Bindung
- oder mit spezifischer Objekt-Variable
Dim datTbsNT As DAO.DBEngine.36 ' As DAO.DBEngine.36 bewirkt frühe Bindung
Set datTbsNT = New DAO.DBEngine.36 - bzw.
Dim datTbsNT As DAO.DBEngine.36 ' As DAO.DBEngine.36 bewirkt frühe Bindung
Set datTbsNT = CreateObject( "DAO.DBEngine.36" ) 2) Späte Bindung:
- mit unspezifischer Objekt-Variable
Dim datTbsNT As Object ' As Object bewirkt späte Bindung
Set datTbsNT = New DAO.DBEngine.36 - bzw.
Dim datTbsNT As Object ' As Object bewirkt späte Bindung
Set datTbsNT = CreateObject( "DAO.DBEngine.36" ) Bei später Bindung kannst Du dann zunächst einmal nicht mehr mit Me.datTbsNT.xyz auf das Control zugreifen, sondern mit datTbsNT.xyz
Das bedeutet aber: eine Umstelleung von früher Bindung (per Drag & Drop) auf späte Bindung (per unspezifischer Objekt-Variable) ist nicht mal so eben nebenbei gemacht . . .
Alternativ bleibt Dir noch die Möglichkeit Deine Dao360.dll doch auf die neuste Version upzudaten.
Du kannst ja mal die neuste Version der Dao360.dll vom Windows 10-Rechner in einen eigenen Ordner auf Deinen Windows XP-Rechner kopieren und dann mit dem Dependency Walker öffnen. Wenn es dann keine Probleme mit den direkt unterlagerten DLLs der nächst unteren Ebene gibt (wovon ich stark ausgehe) wird die neue Version auch unter XP funktionieren.
Gruß, Stefan
Beitrag wurde zuletzt am 04.01.17 um 21:48:17 editiert. | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: visualfx | | Datum: 05.01.17 11:14 |
| Hallo Rippler,
da Du Deine DAO-Objekte ja schon mal von der frühen Bindung auf die späte Bindung umgestellt hast, habe ich eine Bitte an Dich:
- schildere Rainer doch mal, wie Du das bei Dir gemacht hast
Bei meinem letzten Post gestern abend (04.01.2017) um 21:32 habe ich das zwar grundsätzlich beschrieben, bei DAO-Objekten habe ich es jedoch konkret selber noch nicht gemacht.
Danke, Stefan | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: Rippler | | Datum: 05.01.17 15:19 |
| statt:
Dim DB As Database
Dim RS As Recordset
dieses:
Dim DB As Object
Dim RS As Object
alles andere blieb gleich.
Auch das setzen des Verweises auf DAO36
kurzer Auszug eines Source:
Dim DB As Database
Dim RS As Recordset
Set DB = OpenDatabase("Pfad.mdb")
Set RS = DB.OpenRecordset("Tabelle", dbOpenDynaset)
Text1.Text = RS!Spalte1
Text2.Text = RS!Spalte2
Text3.Text = RS!Spalte3
RS.Close
DB.Close
Dim DB As Object
Dim RS As Object
Set DB = OpenDatabase("Pfad.mdb")
Set RS = DB.OpenRecordset("Tabelle", dbOpenDynaset)
Text1.Text = RS!Spalte1
Text2.Text = RS!Spalte2
Text3.Text = RS!Spalte3
RS.Close
DB.Close | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: Oggi | | Datum: 05.01.17 16:07 |
| Howdy,
ich verwende das Datenbanksteuermodul und weise jedesmal ohne Dimensionierung einer Variablen die Daten direkt zu. Wohl hatte ich deshalb noch nie die von 'Rippler' geschilderten Probleme mit der frühen Bindung und den verschiedenen DAO350 und DAO360 Versionen.
Da fällt mir noch ein: die DAO2535.tlb sollte auch in Ordner ..\Common Files stehen.
Data1.DatabaseName = App.Path & "\Datenbankname.mdb"
Data1.RecordSource = "select * from Tabelle order by Name, Titel")
Data1.Refresh
...
...
Data1.Database.Close
Beitrag wurde zuletzt am 05.01.17 um 16:19:58 editiert. | |
| Re: DB-Nutzung unter Windows 10 | | | | Autor: Rainer | | Datum: 05.01.17 18:24 |
| Hallo Stefan, Oggi und Rippler,
ich habe mich so lange nicht gemeldet, weil ich auf die Idee kam, daß es vielleicht gehen könnte, wenn die IDE von VB6 unter Win10 (32Bit) installiert und die EXE-Datei in diesem Milieu generiert wird. Was das Gesamtergebnis betrifft - leider Fehlanzeige. Außerdem kommt die IDE beim Erzeugung von DLL-Dateien nicht mit der Registry von Win10 zurecht. Man muß also die erzeugte DLL-Datei mit REGSVR32 manuell in die Registry aufnehmen. Auch mit dieser Generierung verlangt das Programm die DAO350.DLL für die Arbeit mit dem DATA-Control.
Es bleiben mir also zwei Möglichkeiten:
1. Ich ersetze alle DATA-Controls mit dem manuellen Zugriff auf die Tabellen der Datenbank.
2. Ich stelle die DATA-Controls auf die späte Bindung um.
Ich kann derzeit nicht abschätzen, was mit mehr Aufwand und einem geringeren Risiko neue Fehler einzubauen verbunden ist. Die Entscheidung fälle ich, wenn der Schock überwunden ist.
Ich danke Euch Drei für den sehr interessanten Dialog, der mich hoffentlich nun in die Lage versetzt in einer der beiden Varianten das Problem zu lösen.
Gruß, Rainer. | |
 | 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 |
 |
|
sevZIP40 Pro DLL 
Zippen und Unzippen wie die Profis!
Mit nur wenigen Zeilen Code statten Sie Ihre Anwendungen ab sofort mit schnellen Zip- und Unzip-Funktionen aus. Hierbei lassen sich entweder einzelnen Dateien oder auch gesamte Ordner zippen bzw. entpacken. Weitere InfosTipp des Monats Access-Tools Vol.1 
Über 400 MByte Inhalt
Mehr als 250 Access-Beispiele, 25 Add-Ins und ActiveX-Komponenten, 16 VB-Projekt inkl. Source, mehr als 320 Tipps & Tricks für Access und VB
Nur 24,95 EURWeitere Infos
|
Mai 2024
Sie sind aktuell nicht angemeldet.