13
Dynamische Access-Datenbank für heteroegene Workstation
Access Datenbank programmiert in Access 2003 32bit auf Windows XP
eingesetzt aber auf Windows XP mit/ohne Access Runtime (2007 - 2010) - mal 32bit/64bit
Hallo,
ich habe eine kniffliche Aufgabe für eine von mir programmierte Access-Datenbank und zwar wird diese nach der Kraut & Rüben-Taktik benutzt, also auf Windows XP mit Access Runtime oder das große Access, auf Windows 7 32/64 bit mit Office 2007 32bit und zum Schluss auf Windows 7 64bit mit Office 2010 64bit.
Irgend wie muss man ständig bei neuen Releases 8 verschiedene Versionen machen und das nervt so allmählig. Vorallendingen die Kollegen, wenn gleich beim Starten der Datenbank ein Fehler entsteht, weil dann doch irgend etwas vergessen wurde zu hinterlegen.
Gibt es eine Möglichkeit beim Starten der Datenbank alle relevanten Daten also Prozessorstruktur und Office-Version zu ermitteln und danach die VBA-Verweise auf DAO 2.5 / 3.5 oder 3.6 zu konfigurieren und natürlich bei Funktionsdeklaration PTRSAFE hinzu zu fügen.
Ich weiß nicht so recht, wo ich da genau ansetzen soll.
Schöne Grüße
Axel
eingesetzt aber auf Windows XP mit/ohne Access Runtime (2007 - 2010) - mal 32bit/64bit
Hallo,
ich habe eine kniffliche Aufgabe für eine von mir programmierte Access-Datenbank und zwar wird diese nach der Kraut & Rüben-Taktik benutzt, also auf Windows XP mit Access Runtime oder das große Access, auf Windows 7 32/64 bit mit Office 2007 32bit und zum Schluss auf Windows 7 64bit mit Office 2010 64bit.
Irgend wie muss man ständig bei neuen Releases 8 verschiedene Versionen machen und das nervt so allmählig. Vorallendingen die Kollegen, wenn gleich beim Starten der Datenbank ein Fehler entsteht, weil dann doch irgend etwas vergessen wurde zu hinterlegen.
Gibt es eine Möglichkeit beim Starten der Datenbank alle relevanten Daten also Prozessorstruktur und Office-Version zu ermitteln und danach die VBA-Verweise auf DAO 2.5 / 3.5 oder 3.6 zu konfigurieren und natürlich bei Funktionsdeklaration PTRSAFE hinzu zu fügen.
Ich weiß nicht so recht, wo ich da genau ansetzen soll.
Schöne Grüße
Axel
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 155709
Url: https://administrator.de/forum/dynamische-access-datenbank-fuer-heteroegene-workstation-155709.html
Ausgedruckt am: 23.12.2024 um 17:12 Uhr
13 Kommentare
Neuester Kommentar
Ich weiß nicht so recht, wo ich da genau ansetzen soll.
Ein Tipp: Nicht da, wo du grade ansetzen willst.
Die Lösung heißt hier wegwerfen und richtig machen.
Entweder webbasiert oder mit einem Programm was eine API für den DB-Zugriff benutzt.
Einem User einen direkten Zugriff auf eine Datenbank zu gewähren ist eine Unart von Microsoft und sollte nie benutzt werden.
Ich weiß nicht so recht, wo ich da genau ansetzen soll.
Wäre es nicht viel, viel einfacher, das Ganze auf den kleinsten gemeinsamen Nenner zu bringen???
Hallo,
also Eure zynischen Bemerkungen sind jetzt nicht wirklich hilfreich. Da hätte ich mir das getippe auch sparen können.
@dog
Von Access & VBA auf webbasiert / API ist schon eine Hausnummer, die vor allen Dingen nicht jeder beherrscht.
Nicht jeder hat die Weisheit mit Löffeln gegessen, da wäre das Leben viel zu langweilig, darum habe ich mir gedacht.
Gibt es andere, die konstruktive Lösungen beizutragen haben.
Gruß Axel
also Eure zynischen Bemerkungen sind jetzt nicht wirklich hilfreich. Da hätte ich mir das getippe auch sparen können.
@dog
Von Access & VBA auf webbasiert / API ist schon eine Hausnummer, die vor allen Dingen nicht jeder beherrscht.
Nicht jeder hat die Weisheit mit Löffeln gegessen, da wäre das Leben viel zu langweilig, darum habe ich mir gedacht.
Gibt es andere, die konstruktive Lösungen beizutragen haben.
Gruß Axel
Moin Moin,
du hast eine Frontend / Backend Lösung laufen?
Wenn Ja:
- Backend ist eine Access 2003 Version mit allen Tabellen
- Frontend ist min. Access 2003 da es von allen Programmen genutzt werden kann
- die Access 2007 Runtime (kostenlos) ist auf ALLEN PCs installiert
- auch auf dem PC mit vollem Access wird die Runtime mit deinem Frontend geladen.
Wenn Nein:
- dringend auf Frontend / Backend umstellen und nur die eine Runtime 2007 für alle nutzen!
Alles andere ist tödlich, wie du gerade merkst.
Grüße aus Rostock
Wolfgang
(Netwolf)
du hast eine Frontend / Backend Lösung laufen?
Wenn Ja:
- Backend ist eine Access 2003 Version mit allen Tabellen
- Frontend ist min. Access 2003 da es von allen Programmen genutzt werden kann
- die Access 2007 Runtime (kostenlos) ist auf ALLEN PCs installiert
- auch auf dem PC mit vollem Access wird die Runtime mit deinem Frontend geladen.
Wenn Nein:
- dringend auf Frontend / Backend umstellen und nur die eine Runtime 2007 für alle nutzen!
Alles andere ist tödlich, wie du gerade merkst.
Grüße aus Rostock
Wolfgang
(Netwolf)
War durchaus nicht zynisch gemeint. Siehe Antwort von NetWolf.....
Guten Morgen,
ich bin auf den letzten Metern bis zum Ziel und habe es vorläufig geschafft, dass das Betriebssystem, die Prozessorarchitektur und Office-Version nicht mehr interessant sind für meine Datenbank. Kleine Schummeltricks waren natürlich erlaubt.
Stoße trotzdem dabei auf ein Problem und zwar das was eigentlich in aller erster Linie die beiden 32bit und 64bit Datenbanken von einander unterscheidet ist die Deklaration von Funktionen im Zugriff auf externe Bibliotheken und APIs.
Bei 64bit muss ja zwischen Declare und Function PtrSafe und das habe ich schlaufüchsig so gemacht, dass ich genau diese Statements (mit und ohne PtrSafe) und die darauf aufbauenden Funktionen beim Starten der Datenbank lade, je nachdem was environ("PROCESSOR_ARCHITECTURE") mir so erzählt.
Also jetzt kurz und bündig - Module werden völlig korrekt geladen, nur kann ich beim Beenden der Datenbank das Modul nicht löschen, zumindest nicht aus dem Visual Basic Bereich. Im Navigationsfenster ist das Modul gelöscht.
Wie lösche ich jetzt nicht nur im Navigationsfenster das Modul, sondern auch im Visual Basic Fenster???
Grüße
Axel
ich bin auf den letzten Metern bis zum Ziel und habe es vorläufig geschafft, dass das Betriebssystem, die Prozessorarchitektur und Office-Version nicht mehr interessant sind für meine Datenbank. Kleine Schummeltricks waren natürlich erlaubt.
Stoße trotzdem dabei auf ein Problem und zwar das was eigentlich in aller erster Linie die beiden 32bit und 64bit Datenbanken von einander unterscheidet ist die Deklaration von Funktionen im Zugriff auf externe Bibliotheken und APIs.
Declare Function GetUserName Lib "advapi32.dll" Alias "GetUserNameA" (ByVal lpBuffer As String, nSize As Long) As Long
Declare Function apiGetComputerName Lib "kernel32" Alias "GetComputerNameA" (ByVal lpBuffer As String, nSize As Long) As Long Bei 64bit muss ja zwischen Declare und Function PtrSafe und das habe ich schlaufüchsig so gemacht, dass ich genau diese Statements (mit und ohne PtrSafe) und die darauf aufbauenden Funktionen beim Starten der Datenbank lade, je nachdem was environ("PROCESSOR_ARCHITECTURE") mir so erzählt.
Also jetzt kurz und bündig - Module werden völlig korrekt geladen, nur kann ich beim Beenden der Datenbank das Modul nicht löschen, zumindest nicht aus dem Visual Basic Bereich. Im Navigationsfenster ist das Modul gelöscht.
Wie lösche ich jetzt nicht nur im Navigationsfenster das Modul, sondern auch im Visual Basic Fenster???
Grüße
Axel
Hurra, ist Freitag ;)
ich bin auf den letzten Metern bis zum Ziel und habe es vorläufig geschafft, dass das Betriebssystem, die
Prozessorarchitektur und Office-Version nicht mehr interessant sind für meine Datenbank. Kleine Schummeltricks waren
natürlich erlaubt.
Stoße trotzdem dabei auf ein Problem und zwar das was eigentlich in aller erster Linie die beiden 32bit und 64bit
Datenbanken von einander unterscheidet ist die Deklaration von Funktionen im Zugriff auf externe Bibliotheken und APIs.
Bei 64bit muss ja zwischen Declare und Function PtrSafe und das habe ich schlaufüchsig so gemacht, dass ich genau diese
Statements (mit und ohne PtrSafe) und die darauf aufbauenden Funktionen beim Starten der Datenbank lade, je nachdem was
environ("PROCESSOR_ARCHITECTURE") mir so erzählt.
Wie hast Du das gelöst? Lädst Du ein komplettes Modul dynamisch?
Wenn es sich nur um die 2 Api-Deklarationen handelt die angepasst werden müssen, bietet sich vllt auch die Methode 'insertLines' an
Also jetzt kurz und bündig - Module werden völlig korrekt geladen, nur kann ich beim Beenden der Datenbank das Modul
nicht löschen, zumindest nicht aus dem Visual Basic Bereich. Im Navigationsfenster ist das Modul gelöscht.
Wie lösche ich jetzt nicht nur im Navigationsfenster das Modul, sondern auch im Visual Basic Fenster???
zur Laufzeit kannst Du Module so löschen:
Ebenfalls Grüße
ich bin auf den letzten Metern bis zum Ziel und habe es vorläufig geschafft, dass das Betriebssystem, die
Prozessorarchitektur und Office-Version nicht mehr interessant sind für meine Datenbank. Kleine Schummeltricks waren
natürlich erlaubt.
Stoße trotzdem dabei auf ein Problem und zwar das was eigentlich in aller erster Linie die beiden 32bit und 64bit
Datenbanken von einander unterscheidet ist die Deklaration von Funktionen im Zugriff auf externe Bibliotheken und APIs.
> Declare Function GetUserName Lib "advapi32.dll" Alias "GetUserNameA" (ByVal lpBuffer As String, nSize As Long)
> As Long
> Declare Function apiGetComputerName Lib "kernel32" Alias "GetComputerNameA" (ByVal lpBuffer As String, nSize
> As Long) As Long
> Bei 64bit muss ja zwischen Declare und Function PtrSafe und das habe ich schlaufüchsig so gemacht, dass ich genau diese
Statements (mit und ohne PtrSafe) und die darauf aufbauenden Funktionen beim Starten der Datenbank lade, je nachdem was
environ("PROCESSOR_ARCHITECTURE") mir so erzählt.
Wie hast Du das gelöst? Lädst Du ein komplettes Modul dynamisch?
Wenn es sich nur um die 2 Api-Deklarationen handelt die angepasst werden müssen, bietet sich vllt auch die Methode 'insertLines' an
Application.Modules("modul1").InsertLines 1, "option Explicit" Also jetzt kurz und bündig - Module werden völlig korrekt geladen, nur kann ich beim Beenden der Datenbank das Modul
nicht löschen, zumindest nicht aus dem Visual Basic Bereich. Im Navigationsfenster ist das Modul gelöscht.
Wie lösche ich jetzt nicht nur im Navigationsfenster das Modul, sondern auch im Visual Basic Fenster???
zur Laufzeit kannst Du Module so löschen:
Application.VBE.ActiveVBProject.VBComponents.Remove _
Application.VBE.ActiveVBProject.VBComponents("Modul2")) Grüße
Axel
Axel
Ebenfalls Grüße
Hallo,
ja es ist Freitag. Ich freue mich auch.
Ja ich lade 2 Module dynamisch, je nachdem was mir Umgebungsvariablen als Architektur aussagen. Wobei dein Vorschlag auch nicht schlecht klingt.
Ich habe vor meinem eigentliche Startformular ein Formular gepackt, dass diesen Code aufruft.
Dann der Code mit dem Modul löschen, habe ich ja schon drin, nur löscht er mir nur das Modul im Navigationsfenster, nicht im VB-Editor-Bereich und das stört beim zweiten Aufruf das System.
Also war die Frage, wie ich jetzt defintiv das Modul auch im VB-Editor löschen kann.
Gruß
Axel
ja es ist Freitag. Ich freue mich auch.
Ja ich lade 2 Module dynamisch, je nachdem was mir Umgebungsvariablen als Architektur aussagen. Wobei dein Vorschlag auch nicht schlecht klingt.
Ich habe vor meinem eigentliche Startformular ein Formular gepackt, dass diesen Code aufruft.
Private Sub Form_Open(Cancel As Integer)
On Error Resume Next
' Bibliotheken einbinden
Dim lib_vbe As Object
Dim lib_dao As Object
lib_vbe = Application.VBE.ActiveVBProject.References.AddFromGuid("{0002E157-0000-0000-C000-000000000046}", 5, 3)
' DAO Bibliothek zum Datenbankzugriff
Set lib_dao = Application.VBE.ActiveVBProject.References
lib_dao.AddFromFile Application.CurrentProject.Path & "\DAO\dao2535.tlb"
func_ModulLoeschen ("mod_Allgemein")
func_ModulLaden
DoCmd.OpenForm "frm_Main"
Cancel = True
End SubPublic Function func_ModulLaden()
On Error Resume Next
Dim envstring As String
envstring = Environ("PROCESSOR_ARCHITECTURE")
If envstring = "x86" Then ' 32bit System
Application.LoadFromText acModule, "mod_Allgemein", CurrentProject.Path & "\32bit.bas"
ElseIf envstring = "AMD64" Then '64bit System
Application.LoadFromText acModule, "mod_Allgemein", CurrentProject.Path & "\64bit.bas"
Else
MsgBox "Kann System nicht identifizieren, lade die 32bit Variante..."
Application.LoadFromText acModule, "mod_Allgemein", CurrentProject.Path & "\32bit.bas"
End If
Exit Function
End FunctionDann der Code mit dem Modul löschen, habe ich ja schon drin, nur löscht er mir nur das Modul im Navigationsfenster, nicht im VB-Editor-Bereich und das stört beim zweiten Aufruf das System.
Also war die Frage, wie ich jetzt defintiv das Modul auch im VB-Editor löschen kann.
Gruß
Axel
Wie sieht Dein func_modulLöschen aus? Die von mir gepostete Methode löscht das Modul auch im VB-Editor (habs mit A2007 getestet).
Ansonsten lösche mal testweise ein anderes Modul. Ich könnte mir vorstellen, dass in dem Modul noch Objekte geladen sind und das das Modul deswegen nicht gelöscht wird (vermutung).
BTW: Eine Sache solltest Du im Hinterkopf behalten. Manche Virenscanner mögen es gar nicht wenn ein Code zur Laufzeit geändert wird. Hatte da vor ein paar Jahren mal Probleme mit
Ansonsten lösche mal testweise ein anderes Modul. Ich könnte mir vorstellen, dass in dem Modul noch Objekte geladen sind und das das Modul deswegen nicht gelöscht wird (vermutung).
BTW: Eine Sache solltest Du im Hinterkopf behalten. Manche Virenscanner mögen es gar nicht wenn ein Code zur Laufzeit geändert wird. Hatte da vor ein paar Jahren mal Probleme mit
Public Function func_ModulLoeschen(modName As String)
On Error Resume Next
Application.VBE.ActiveVBProject.VBComponents.Remove Application.VBE.ActiveVBProject.VBComponents(modName)
End FunctionDas mit dem Virenscanner habe ich auch Durch. Das ganze Jahr schon. Kaspersky zerschreddert hin und wieder je nachdem wie gerade das Wetter ist oder so unsere Windows-Login-Skripte oder Batch-Skripte.
Wenn wir Glück haben, dann stellt Kaspersky die nur unter Quarantäne und löscht diese nicht. Manchmal haben wir Pech! ;-(
> On Error Resume Next
>
Guten Morgen,
schade, dass schon wieder Montag ist
Also ich habe das Problem zumindest mit der API-Deklaration umgangen, da mir Environ("username") bzw. Environ("computername") näher gelegt wurden. Klappt wunderbar damit, aber du hattest recht, das mit dem Modul geladen.
Ich lade aber immer noch dynamisch die DAO-Verweise und das klappt ausgezeichnet. Somit funktioniert mein Vorhaben der I14Y wunderbar.
Im Form.Close des Hautpformulars wollte ich alle Tabellen löschen und schreibe mir Logindaten in das Backend. Dabei greife ich natürlich auf den angemeldeten Benutzer- und Computernamen zurück, der genau diese API-Deklaration benötigt. Deshalb konnte das Modul nicht gelöscht werden.
Also Vielen Vielen Dank für Eure/Deine Hilfe.
Schöne Grüße und weiterschlafen
Axel
schade, dass schon wieder Montag ist
Also ich habe das Problem zumindest mit der API-Deklaration umgangen, da mir Environ("username") bzw. Environ("computername") näher gelegt wurden. Klappt wunderbar damit, aber du hattest recht, das mit dem Modul geladen.
Ich lade aber immer noch dynamisch die DAO-Verweise und das klappt ausgezeichnet. Somit funktioniert mein Vorhaben der I14Y wunderbar.
Im Form.Close des Hautpformulars wollte ich alle Tabellen löschen und schreibe mir Logindaten in das Backend. Dabei greife ich natürlich auf den angemeldeten Benutzer- und Computernamen zurück, der genau diese API-Deklaration benötigt. Deshalb konnte das Modul nicht gelöscht werden.
Also Vielen Vielen Dank für Eure/Deine Hilfe.
Schöne Grüße und weiterschlafen
Axel
Hallo,
"Ich weiß nicht so recht, wo ich da genau ansetzen soll."
ich denke, die Lösung zumindest eines Teils der Probleme könnte hier in "Bedingter Kompilierung" liegen.
Der folgende Artikel liefert nähere Informationen und Beispiele hierzu:
http://msdn.microsoft.com/de-de/library/ee691831.aspx
"Ich weiß nicht so recht, wo ich da genau ansetzen soll."
ich denke, die Lösung zumindest eines Teils der Probleme könnte hier in "Bedingter Kompilierung" liegen.
Der folgende Artikel liefert nähere Informationen und Beispiele hierzu:
http://msdn.microsoft.com/de-de/library/ee691831.aspx
