none
Access 2003 unter Windows 7 64 bit

    Question

  • Access 2003 unter Windows 7 (64 bit)

    Hallo! Es gibt zwar schon ähnliche Fragen zu diesem Thema, kann aber für mein Problem keine konkrete Lösung finden. Es geht um folgendes:
    Habe eine Access-DB u.a. zur Personalverwaltung angelegt. Die läuft seit einigen Jahren problemlos. Seit Kurzem haben wir einen neuen Rechner im Büro mit Windows 7 (64 bit). Auf allen anderen Rechnern laufen 32-Bit-Versionen (teils Windows 7, teils Vista). Auf dem 64-Bit-Rechner läuft die DB auch, nur an einer Stelle gibt es immer wieder ein Problem. Wenn ich im Formular zur Personalverwaltung das Kombinationsfeld zur Namenssuche verwenden möchte bekomme ich ständig die Fehlermeldung "Laufzeitfehler '48' - Fehler bei Laden einer DLL". Die Möglichkeit zum Debuggen wird angeboten. Wenn ich darauf klicke, öffnet sich das VBA Fenster und die fehlerauslösende Prozedur wird angezeigt:

    Private Sub Kombinationsfeld1015_AfterUpdate()
        ' Den mit dem Steuerelement übereinstimmenden Datensatz suchen.
        Dim rs As Object

        Set rs = Me.Recordset.Clone
        rs.FindFirst "[PersonalNr] = " & Str(NZ(Me![Kombinationsfeld1015], 0))
        If Not rs.EOF Then Me.Bookmark = rs.Bookmark
    End Sub

    Hier bin ich mit meinem Latein am Ende. Was kann ich tun? Vielleicht noch ein Hinweis: Bin kein VBA-Experte. Erklärungen nach Möglichkeit im Stil "VBA für Dummies" ;-)

    Gruss Markus
    Thursday, April 11, 2013 11:45 AM

Answers

  • Hallo!

    So, habe nun nach eigener Recherche in den Tiefen des Internets die Lösung für das Problem gefunden.

    Im VBA-Code muss die Zeile

    Dim rs As Object

    ersetzt werden mit

    Dim rs As DAO.Recordset

    ...und schon funktioniert's!

    Trotzdem ein großes "Dankeschön!" an alle, die sich Zeit genommen haben, sich mit diesem Problem zu beschäftigen und Lösungsvorschäge unterbreitet haben. Ein besonderer Dank an Henry, der mich noch einmal bestärkt hat, das Projekt grundsätzlich auf eine andere Basis zu stellen (siehe letzter Eintrag von Henry)!

    Gruss

    Markus

    Thursday, April 18, 2013 7:31 AM

All replies

  • Am 11.04.2013 schrieb Markus_Bln:

    Personalverwaltung das Kombinationsfeld zur Namenssuche verwenden möchte bekomme ich ständig die Fehlermeldung "Laufzeitfehler '48' - Fehler bei Laden einer DLL". Die Möglichkeit zum Debuggen wird angeboten. Wenn ich darauf klicke, öffnet sich das VBA Fenster und die fehlerauslösende Prozedur wird angezeigt:

    Und welche Zeile wird markiert?

    Private Sub Kombinationsfeld1015_AfterUpdate()

    Die Benennung von diesem Steuerelement ist unglücklich. Das kann man
    besser machen.

        ' Den mit dem Steuerelement übereinstimmenden Datensatz suchen.
        Dim rs As Object

        Set rs = Me.Recordset.Clone
        rs.FindFirst "[PersonalNr] = " & Str(NZ(Me![Kombinationsfeld1015], 0))
        If Not rs.EOF Then Me.Bookmark = rs.Bookmark
    End Sub

    Starte die Datenbank und drück ALT + F11. Im VBA-Editor das Menü
    Extras > Verweise. Gibt es hier Verweise, die Nicht Vorhanden sind?
    Wenn ja, deaktivieren, speichern und schliessen. Funktioniert es
    jetzt?

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Thursday, April 11, 2013 4:49 PM
  • Hallo Winfried!

    Danke für die schnelle Antwort. Also, markiert ist die Zeile

    Set rs = Me.Recordset.Clone

    Ja, ich weiß, die Bezeichnung für das Kombinationsfeld ist nicht so professionell, allerdings war ich beim Entwerfen der DB noch nicht bei den Namenskonventionen angelangt....

    Verweise habe ich geprüft: alle vorhanden!

    Gruss

    Markus

    Friday, April 12, 2013 10:43 AM
  • Am 12.04.2013 schrieb Markus_Bln:

    Danke für die schnelle Antwort. Also, markiert ist die Zeile

    Set rs = Me.Recordset.Clone

    Dieser Artikel zeigt wie es richtig geht:
    http://www.donkarl.com?FAQ4.4

    rs als Object deklarieren ist nicht in Ordnung.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Friday, April 12, 2013 2:31 PM
  • Hallo,

    "Laufzeitfehler '48' - Fehler bei Laden einer DLL". Die Möglichkeit zum Debuggen wird angeboten. Wenn ich darauf klicke, öffnet sich das VBA Fenster und die fehlerauslösende Prozedur wird angezeigt:

    Private Sub Kombinationsfeld1015_AfterUpdate()
        ' Den mit dem Steuerelement übereinstimmenden Datensatz suchen.
        Dim rs As Object

        Set rs = Me.Recordset.Clone
        rs.FindFirst "[PersonalNr] = " & Str(NZ(Me![Kombinationsfeld1015], 0))
        If Not rs.EOF Then Me.Bookmark = rs.Bookmark
    End Sub

    Neben Winfrieds Kommentaren probier auch mal folgendes:

    - Alle Module pruefen, folgende Kopfzeilen sollten vorhanden sein:

    Option Compare <Parameter>
    Option Explicit

    <Parameter> steht standardmaessig auf "Database", d. h. Option Compare Database

    - Im VB-Editor im Menue Debug - Kompilieren.

    Falls der Compiler Fehler findet, beheben.

    Gruss - Peter

    Sunday, April 14, 2013 2:00 PM
  • Hallo Winfried,

    Am 12.04.2013 schrieb Markus_Bln:

    Danke für die schnelle Antwort. Also, markiert ist die Zeile

    Set rs = Me.Recordset.Clone

    Dieser Artikel zeigt wie es richtig geht:
    http://www.donkarl.com?FAQ4.4

    rs als Object deklarieren ist nicht in Ordnung.

    Doch, man verliert zwar waehrend der Entwicklung den Komfort von Intellisense (DAO bzw. ACEDAO ist einer der Standard-Verweise) aber die Funktionalitaet ist voll gegeben. Das Problem ist Me.Recordset.Clone. Richtig heisst es Me.RecordsetClone.

    Gruss - Peter

    Sunday, April 14, 2013 2:05 PM
  • Am 14.04.2013 schrieb Peter Doering [MVP]:
    Hallo Peter,

    Am 12.04.2013 schrieb Markus_Bln:

    Danke für die schnelle Antwort. Also, markiert ist die Zeile

    Set rs = Me.Recordset.Clone

    Dieser Artikel zeigt wie es richtig geht:
    http://www.donkarl.com?FAQ4.4

    rs als Object deklarieren ist nicht in Ordnung.

    Doch, man verliert zwar waehrend der Entwicklung den Komfort von Intellisense (DAO bzw. ACEDAO ist einer der Standard-Verweise) aber die Funktionalitaet ist voll gegeben. Das Problem ist Me.Recordset.Clone. Richtig heisst es Me.RecordsetClone.

    das habe ich vollkommen 'überlesen'. ;)
    Mit Option Explict wäre dem OP das nicht passiert. ;)

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Sunday, April 14, 2013 6:43 PM
  • Hallo Winfried

    "Winfried Sonntag [MVP]" schrieb im Newsbeitrag news:f15a3d96-debb-46f9-929e-a010868021e7@communitybridge.codeplex.com...

    Richtig heisst es Me.RecordsetClone.

    das habe ich vollkommen 'überlesen'. ;)
    Mit Option Explict wäre dem OP das nicht passiert. ;)

    Falsch, da rs As Object deklariert ist, können Methoden und Eigenschaften erst zur Laufzeit aufgelöst werden, wenn das Objekt bereits instanziiert wurde. Da ist ja gerade der Trick hinter dem Late Binding.
    Da hilft auch kein Option Explicit. Das würde zum Kompilationszeitpunkt nur meckern, wenn rs nicht deklariert worden wäre. Sobald es Object sieht, macht der Compiler einen Bogen um das Objekt und verlässt sich drauf, dass der Benutzer wohl das richtige gemacht hat. Zur Laufzeit gibt es dann einen Fehler "Method or Property not found.".

    Gruss
    Henry

    Gruss
    Henry

    Monday, April 15, 2013 2:37 AM
  • Am 15.04.2013 schrieb Henry Habermacher:

    "Winfried Sonntag [MVP]" schrieb im Newsbeitrag news:f15a3d96-debb-46f9-929e-a010868021e7@communitybridge.codeplex.com...

    Richtig heisst es Me.RecordsetClone.

    das habe ich vollkommen 'überlesen'. ;)
    Mit Option Explict wäre dem OP das nicht passiert. ;)

    Falsch,

    Richtig! Ich meinte genau das, was Du zitiert hast: Me.RecordsetClone.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Monday, April 15, 2013 5:06 AM
  • Hallo an Winfried, Peter und Henry!

    Habe Me.Recordset.Clone in Me.RecordsetClone umgeschrieben - kein Erfolg.

    Habe Option Compare Database ergänzt um Option Explicit - kein Erfolg.

    Habe im VB-Editor den Compiler Fehler suchen lassen - er hat keine gefunden.

    Das Einzige, das ich noch nicht probiert habe, ist die Alternative von www.donkarl.com. Falls es dann einen Erfolg gibt (glaube langsam nicht mehr daran), werde ich Bescheid geben.

    Erst einmal aber vielen Dank für die Lösungsvorschläge bis hierher und Eure Mühe.

    Gruss

    Markus

    Monday, April 15, 2013 11:50 AM
  • Hallo Markus,

    schau mal nach, ob du unter Extras|Verweise im VBA-Editor die Datei

    MSCOMCT2.OCX

    registriert hast. Wenn Ja, dann lösche den Verweis (Häkchen  raus), schließe die Verweise, öffne sie erneut und suche die Datei erneut in c:\windows\syswow64 und registriere sie neu.


    It's no problem, it's just the syntax

    Monday, April 15, 2013 2:07 PM
  • Hallo Roland!

    Nun abgesehen von der Tatsache, dass auf dem 64-Bit-System noch die Vorgängerversion dieser Datei existierte und ich dann die neuere Version nachinstallieren musste, hat dies leider auch keine Verbesserung gebracht. 

    Da die DB ja auf allen 32-Bit-Systemen anstandslos läuft, denke ich, dass es am 64-Bit-System liegt. 

    Danke dennoch für diesen Vorschlag!

    Gruss Markus

    Tuesday, April 16, 2013 11:42 AM
  • Hallo Markus

    Du gehst davon aus, dass Office in der gleichen Bittigkeit installiert ist, wie Windows. Das ist in der Regel nicht der Fall. Es ist nicht relevant, ob Win7 in 32-bit oder 64-bit installiert ist, sondern welches Office installiert wurde. Wenn das System 64-bittig läuft, heisst das noch lange nicht, dass Office auch 64-bit ist. In Win7 64-bit gibt es die WOW64 (Windows 32 bit on Windows 64-bit), welche oben kurz angesprochen wurde. MS empfiehlt Office auch auf 64-bit Systemen in der 32-bit Version zu installieren. Das ist die übliche Installationsart.

    Anwendungen in der WOW64 merken nicht, dass diese auf einem 64-bit Windows laufen. Dies bedingt allerdings, dass Du auch die 32-bit Controls installieren musst, da die 32-bit Anwendungen sonst nicht auf diese zugreifen können.

    Falls Du die 64-bit Version von Office installiert hast, dann wirst Du noch ganz andere Probleme feststellen. Die Anwendungen müssen in der Regel migriert werden, speziell die Anwendungen, welche VBA benutzen. Es gibt da einige Unterschiede und es sind noch lange nicht alle Controls in einer 64-bit Version verfügbar, so dass Du hier auf Funktionen verzichten musst, welche auf solchen Controls basieren.

    Bevor Du also weitersuchst: Kontrolliere, ob Dein Office in der 32-bit Version installiert ist. Falls nicht, deinstalliere die 64-bit Version und installiere die 32-bit Version. Installiere dannach die Controls in der 32-bit Version, die Du benötigst und versuche es nochmals.

    Gruss

    Henry

    Wednesday, April 17, 2013 3:21 AM
  • Hallo Henry! 

    Nach meinem Kenntnisstand ist Microsoft Office 2003 nicht in einer 64-bit-Version verfügbar. Es läuft also als 32-Bit-Version auf dem Rechner. Ich finde es eben merkwürdig, dass auf den Rechnern mit Windows 7/Vista (jeweils 32 bit) dieses o.g. Problem nicht auftritt, sondern nur auf dem Rechner mit Windows 7 in der 64 bit-Variante. 

    Gruss 

    Markus

    Wednesday, April 17, 2013 6:42 AM
  • Wo genau (in welcher Zeile) tritt der Fehler auf?

    Einen Decompile hast Du vermutlich schon gemacht, oder?

    Was hast Du auf dem Formular drauf? Irgendwelche Controls, z.B. ein Webbrowser Control? Oder ein ActiveX Control? Controls, die erst zur Laufzeit instanziiert werden und in Win7 evt. nicht enthalten sind?

    Lass' mal diese Zeile Code im Direktfenster laufen

    for each ref in application.References : ? ref.name  & " - " ref.FullPath : next

    und poste dann den Output hier.

    Gruss

    Henry


    Wednesday, April 17, 2013 7:17 AM
  • Hallo Henry!

    Zuerst trat der Fehler in der Zeile

    Set rs = Me.Recordset.Clone

    auf. Peter (weiter oben im Thread) wies dann darauf hin, dass es richtig heißen muss:

    Set rs = Me.RecordsetClone

    Das habe ich korrigiert. Nun wird die Zeile:

     rs.FindFirst "[PersonalNr] = " & Str(NZ(Me![Kombinationsfeld1015], 0))

    als Fehler markiert.

    Wenn mit Decompile gemeint ist, im VBA-Editor auf "Debuggen" und dann auf "Kompilieren" zu klicken, dann habe ich das schon getan - ohne Erfolg. 

    Vielleicht ist noch wichtig zu wissen, dass der Designmaster der DB auf meinem (Windows 7 32bit) Rechner liegt. Die anderen DB's sind Replikate, die mit diesem hier synchronisiert werden. Kann es vielleicht sein, dass beim Anlegen des Replikats auf dem 64bit-Rechner irgendwelche Verweise im "falschen" Verzeichnis gelandet sind, also bspw. ein Verweis auf eine dll im Verzeichnis "syswow64" statt "system32"?

    Gruss 

    Markus

    Wednesday, April 17, 2013 7:38 AM
  • Hallo Markus

    Da hast Du uns sehr bedeutende Informationen vorenthalten. Es ist ein Datenbank Replikat, was draussen läuft. Nicht gut. Replikate sollten für Anwendungen nicht benutzt werden, sondern nur für Tabellen.

    Du solltest die Anwendung mit einer Verteileranwendung verteilen und es sollte eine MDE sein, nicht eine MDB und auf keinen Fall als Replikat. Das ist sehr ungünstig und sehr, sehr fehleranfällig, auch wenn es in einzelnen Umgebungen funktionieren mag.

    Dennoch sehe ich in der nun genannten Zeile einen andere Ungereimtheit, falls die Zeile mittels Copy/Paste in die Anwendung gekommen ist. Die Nz() Funktion heisst bei Dir NZ() (grossgeschrieben). Das deutet auf ein potentielles Problem hin, weil die Gross/Kleinschreibung automatisch korrigiert wird, wenn die Referenz aufgelöst werden kann. Klicke mal mit der rechten Maustaste auf NZ und dann auf "gehe zu Definition". Wird da der Object Browser geöffnet und die Nz() Funktion dort angezeigt?

    Falls ja, dann setze das in VBA wieder auf die normale Schreibung zurück, indem Du:

    Dim Nz As Variant

    irgendwo im Code eintippst und dann Enter drückst. Dannach löschst Du diese Zeile wieder.

    Falls nein, musst Du zuerst mal die doppelte Definition von NZ loswerden. Vielleicht hast Du irgendwo eine Variable mit dem Namen angelegt, oder gar eine Funktion oder eine Sub und die drückt nun rein.

    Des Weiteren machst Du um Nz() ein Str() herum. Was bezweckst Du damit? Willst Du damit eine deutsch formattierte Zahl in eine VBA lesbare Form bringen? Das ist nicht nötig, VBA sollte damit umgehen können, wenn Du den Wert von einer ComboBox ausliest und da es die PersonalNr ist gehe ich davon aus, dass diese nicht als Deutsche Dezimalzahl formattiert wurde. Lass' das Str() mal weg.

    Am Schluss sollte die Zeile so aussehen:

    rs.FindFirst "[PersonalNr] = " & Nz(Me![Kombinationsfeld1015], 0)

    Versuche es dann nochmals.

    Allerdings: Zuerst mal das Replikat loswerden und verwende eine vernünftige Verteilmethode, z.B. den MDBLoader, den es im www.dbdev.org im Download Bereich gibt.

    BTW: Es ist gar nicht so einfach eine Anwendung wieder in einen nicht Replikatszustand umzuwandeln, weil da überall neue Felder hinzugefügt wurden. Falls Du die Anwendung nach FE/BE aufgeteilt hast, ist es einfacher, aber bei Tabellen ist es ziemlich mühsam. Wie's geht findest Du hier:

    MichKa's TSI Un-Replicator

    Gruss

    Henry

    Wednesday, April 17, 2013 8:24 AM
  • Hallo Henry!

    Asche auf mein Haupt! Ahnte nicht, dass das ein so wichtiges Detail ist - bin ja auch kein Profi :-(

    Eine wichtige Sache konnte ich, dank Deines Hinweises, schon lösen. Tatsächlich war im VBA-Code NZ großgeschrieben. Mittels 

    Dim Nz As Variant

    wurde dieser Fehler korrigiert. Ob es jetzt geht, kann ich leider erst etwas später ausprobieren. Du fragst

    "Des Weiteren machst Du um Nz() ein Str() herum. Was bezweckst Du damit?..."

    Das war gar nicht meine Idee. Ich habe das Kombinationsfeld mit Hilfe des Office-Assistenten erstellt. Danach habe ich keine Veränderungen vorgenommen. 

    Das die Replikationsvariante keine optimale Lösung ist, musste ich bereits in der Vergangenheit erfahren. Als ich 2005 die DB entworfen hatte, schien es mir die einfachste Lösung zu sein. Jeder Nutzer der DB sollte Daten eingeben können und mittels Synchronisation dann diese neu eingegebenen Daten den anderen Nutzern zur Verfügung stellen. Die FE/BE-Lösung ist nun ein Schritt, den ich mir für die nahe Zukunft vorgenommen habe. Dazu werde ich einen momentan nicht verwendeten Rechner quasi als Server nutzen, auf dem dann die Tabellen als BE liegen. 

    Ich weiß ja nun, dass ich mich im Notfall hier an Experten wenden kann ;-) 

    Gruss

    Markus


    Wednesday, April 17, 2013 8:59 AM
  • Hallo!

    So, habe nun nach eigener Recherche in den Tiefen des Internets die Lösung für das Problem gefunden.

    Im VBA-Code muss die Zeile

    Dim rs As Object

    ersetzt werden mit

    Dim rs As DAO.Recordset

    ...und schon funktioniert's!

    Trotzdem ein großes "Dankeschön!" an alle, die sich Zeit genommen haben, sich mit diesem Problem zu beschäftigen und Lösungsvorschäge unterbreitet haben. Ein besonderer Dank an Henry, der mich noch einmal bestärkt hat, das Projekt grundsätzlich auf eine andere Basis zu stellen (siehe letzter Eintrag von Henry)!

    Gruss

    Markus

    Thursday, April 18, 2013 7:31 AM
  • Hallo Markus

    Gut, dass Du es selber rausgefunden hast.

    Ich hatte das noch vermutet und darum den Code gepostet, den ich Dich bat in Direktfenster ausführen zu lassen. Da hätten dann sofort die Meisten, die mitlesen gewusst, was schief läuft und Dich auf die FAQ:

    Deutsche Access FAQ

    und dort auf FAQ 7.11 verwiesen.

    Meine bevorzugte Lösung im Gegensatz zu der von Karl das Recordset _immer_ mit DAO.RecordSet zu referenzieren ist die, den Verweis auf die in der Regel überflüssige ADO Library zu entfernen und diesen Ballast abzuwerfen. Dann braucht's das DAO. nicht.

    Gruss

    Henry

    Thursday, April 18, 2013 10:01 AM