none
VBA Code für Datenbankverbindung, die in Access 2013 + Access 2003 funktioniert

    Frage

  • Hallo zusammen,

    ich arbeite an einer Access 2003 Datenbank (Kundenprogramm) und habe eine vollständig nach VBA übertragen. Hierbei arbeite ich mit Workspaces "DBEngine.CreateWorkspace(...)". Zuvor wurde alles über in Access angelegte Abfragen abgearbeitet.

    Das Teilprogramm funktioniert tadellos in Access 2003, aber leider nicht in Access 2013 (hier passiert einfach mal garnichts). Die ursprüngliche Programmversion arbeitet aber nach wie vor zuverlässig.

    Kann mir jemand helfen mit einer Datenbankverbindungssyntax, die in beiden Programmversionen funktioniert?

    Vielen Dank im voraus!

    Björn Münstermann

    Montag, 23. Februar 2015 14:03

Antworten

Alle Antworten

  • Grundsätzlich läuft der VBA Code aus Access 2003 ohne Änderungen in Access 2013, mit wenigen Ausnahmen. Deshalb zuerst in Access 2013 prüfen: Wird der Code fehlerlos kompiliert? Verschwindet das Problem nach Reparieren & Komprimieren?

    Wenn das nicht hilft: Wie wird der Code gestartet? Gibt es Laufzeit-Fehlermeldungen? Die obigen Angaben sind zu knapp, um weiterzuhelfen.

    Matthias Kläy, Kläy Computing AG

    Dienstag, 24. Februar 2015 09:53
  • Hallo,

    vielen Dank für die Rückmeldung.

    Die Kompilierung läuft in beiden Programmen fehlerlos durch.

    Der Code wird durch das ändern eines Formularfeldes aktiviert ("After_Update").  Hierbei bricht der Code direkt ab (wird nicht ausgeführt), ohne Fehlermeldung. Ich vermute, dass das Problem in diesem Verbindungsaufbau liegt, da Access 2013 keine Benutzeranmeldung hat. Hier die Codestruktur

    Dim DBLocal As DAO.Database Dim VisWorkspace As Workspace Dim TabellenAnsicht As DAO.Recordset Dim sql As String Set DBLocal = DBEngine.CreateWorkspace("WSName","User","PW") Set VisWorkspace = WSName.Opendatabase(C:\...\dblocal.mdb) Set TabellenAnsicht = VisWorkspace.Openrecordset("Tabelle")

    'eine Abarbeitung der Rekordsets, die je nach Ergebnis einen anderen SQL String erzeugt sql = "Eine SQL Abfrage"

    DBlocal. execute sql


    Ich benötige 4 verschiedene Recordsets die ineinander verschachtelt abgearbeitet werden und auf 2 Datenbanken arbeiten.

    Eine Idee?


    Dienstag, 24. Februar 2015 13:49
  • Da scheint einiges durcheinandergeraten zu sein, beispielsweise ist die Variable WSName nicht deklariert, und die Variablen DBLocal und VisWorkspace sind in der Rolle vertauscht.

    Folgender Code läuft bei mir problemlos (Access 2013):

    Set VisWorkspace = DBEngine.CreateWorkspace("WSName", "Admin", "")
    Set DBLocal = VisWorkspace.OpenDatabase("C:\...\dblocal.mdb") 
    Set TabellenAnsicht = DBLocal.OpenRecordset("Tabelle")
    TabellenAnsicht.MoveLast
    Debug.Print TabellenAnsicht.RecordCount
     

    Hast du in allen Modulen in der Deklaration "Option Explicit" gesetzt?

    Matthias Kläy, Kläy Computing AG

    Dienstag, 24. Februar 2015 14:28
  • Hallo Björn,

    setzt Du evtl. die 64 Bit Version von Office 2013 ein?

    Poste bitte die genaue Fehlermeldung, die Du erhältst und gib die Codezeile an, die den Fehler verursacht.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community


    Dienstag, 24. Februar 2015 15:32
  • Hallo und vielen Dank für die Anregungen.
    Option Explicit ist in allen Modulen gesetzt

    Wir verwenden die 64Bit Version von Office 2013. Da das Programm in seiner Ursprünglichen Form aber ohne größere Probleme läuft denke ich nicht das es daran liegt, oder muss ich dann bei der Verwendung bestimmter Variablentypen/Funktionen besonders aufpassen?

    WSName war ein Übertragungsfehler meinerseits. Hier der Code den ich parallel getestet habe:

           Set WS = DBEngine.CreateWorkspace("WS", "Admin", "WeMa")
           Set DBWema = CurrentDb
           Set TabelleRessourcenProjektansicht = DBWema.OpenRecordset("T-Ressourcen-Projektansicht")
           TabelleRessourcenProjektansicht.MoveLast
           Debug.Print TabelleRessourcenProjektansicht.RecordCount

    Leider erhalte ich keine Ausgabe...

    Dienstag, 24. Februar 2015 15:48
  • Hallo Björn,

    schau mal hier:

      https://technet.microsoft.com/de-de/library/ee681792.aspx

    dort findest Du einige der Unterschiede, die man bei 64 Bit Office Anwendungen beachten musst.


    Gruß, Stefan
    Microsoft MVP - Visual Developer ASP/ASP.NET
    http://www.asp-solutions.de/ - Consulting, Development
    http://www.aspnetzone.de/ - ASP.NET Zone, die ASP.NET Community

    Dienstag, 24. Februar 2015 15:56
  • Am 24.02.2015 schrieb Björn Münstermann:

    Wir verwenden die 64Bit Version von Office 2013. Da das Programm in seiner Ursprünglichen Form aber ohne größere Probleme läuft denke ich nicht das es daran liegt, oder muss ich dann bei der Verwendung bestimmter Variablentypen/Funktionen besonders aufpassen?

    Auch wenn man ein 64-Bit Windows einsetzt ist immer noch ein 32-Bit
    Office dem 64-Bit Office vorzuziehen.


    Servus
    Winfried

    Gruppenrichtlinien
    HowTos zum WSUS Package Publisher
    WSUS Package Publisher
    HowTos zum Local Update Publisher
    NNTP-Bridge für MS-Foren

    Dienstag, 24. Februar 2015 17:24
  • Vielen Dank für die Hinweise. Um ehrlich zu sein hatte ich völlig übersehen, dass wir nicht nur einen Versionssprung sondern auch einen 32/64bit Wechsel hatten.

    Ich werde prüfen, ob es an dem Office 32/64bit Problem liegt. Die Links waren sehr aufschlussreich!

    Mittwoch, 25. Februar 2015 07:47
  • Guten Morgen,

    habe das Programm nun in einer frischen 32bit installation geprüft. Leider ohne Erfolg. Die Abfrage funktioniert auch in dieser Accessversion nicht.

    Gibt es noch einen anderen Ansatzpunkt?

    Mittwoch, 25. Februar 2015 10:09
  • Du hast immer noch nicht beantwortet, auf welcher Zeile der Fehler entsteht, wenn du mit dem Debugger das Programm zeilenweise ausführst, und welche Fehlermeldung es gibt.

    Unterdrückst du Fehlermeldungen mit On Error Resume Next?

    Matthias Kläy, Kläy Computing AG

    Mittwoch, 25. Februar 2015 10:26
  • Ich habe nun noch ein wenig rumprobiert. Wie gedacht produziert die folgende Zeile den Fehler:

    Set WS = DBEngine.CreateWorkspace("WS","Admin","PW")

    "Laufzeitfehler 3029: Kein zulässiger Kontoname oder kein zulässiges Passwort"

    Die selben Einstellungen funktionieren unter Access 2003 anstandslos.

    Mittwoch, 25. Februar 2015 14:00
  • Hier gibt es einen Unterschied zwischen Access 2003 und 2013: Seit Access 2007 gibt es die ganze Benutzerverwaltung nicht mehr!

    Was geht ist ein leeres Passwort ""

    Matthias Kläy, Kläy Computing AG

    Mittwoch, 25. Februar 2015 14:27
  • Vielen Dank für die Hilfe. Das ist in der Tat das Problem. Leider nimmt 2013 dort nur den "Admin" als gültiges Konto. Da werde ich mal noch ein bisschen was ausprobieren. Aber nun bin ich wenigstens sicher was das Problem ist.

    Vielen Dank mklaey, Winfried Sonntag, Stefan Falz!!
    Donnerstag, 26. Februar 2015 08:13