Probleme mit 32 Bit und 64 Bit

[ThomasFtl]

Ich muss ein größeres Projekt auf 64 Bit umstellen. Die Windows-API-Funktionen sind kein Problem. Das ist reine Fleißarbeit, zumal das nicht so oft vorkommt. Viel problematischer sind die Formulare. Formulare, die unter 32 Bit erstellt wurden lassen sich unter 64 Bit nicht öffnen und umgekehrt. Knackpunkt ist der Aufruf von Funktionen aus Modulen. Sobald so ein Aufruf vorhanden ist, bringt die aufrufende Methode einen Fehler, dass wärend der Kommunikation mit dem OLE-Server oder ActiveX-Steuerelement ein Problem aufgetreten ist. Wenn ich nun unter Access 64 Bit eine exakte Kopie der Problem-Maske manuell neu erstelle und den Code aus der unwilligen Maske im VBA-Editor einfach komplett kopiere und alles speichere, dann lässt sich diese Maske unter Access 64 Bit aufrufen. Aber unter Access 32 Bit kommt dann der besagte Fehler für diese neue Maske.
Gibt es für dieses Problem eine Lösung oder muss ich alle Masken neu designen und den Code dahinter kopieren? Der Aufwand wäre enorm.

Thomas

[markusxy]

Knackpunkt ist der Aufruf von Funktionen aus Modulen.

Das sollte nicht sein.
Versuche mal ein decompile.
Ansonsten, wenn du wirklich ActiveX verwendest müssen die natürlich in 64 Bit verfügbar sein und auf den jeweiligen Formularen/Reports ausgetauscht werden.

[ThomasFtl]

Access 365 32 Bit unter Win 11 Prof Test-DB angelegt mit einer Tabelle. Dann über Erstellen -> Formular Assistent ein neues Formular erstellt. Alles nur Standardelemente, kein zusätzlicher Quellcode. Dazu ein Modul mit einer leeren Sub, die im Load des Formulares aufgerufen wird. Unter 32 Bit alles kein Problem. Aber auf einem anderen PC mit Win 10 64 Bit und Office 64 Bit bringt die Maske beim Öffnen den Fehler. Dann das Spielchen umgekehrt gemacht, also unter Access 64 ein "Standard-Formular" erzeugt mit dem Funktionsaufruf im Load. Das funktioniert unter 64 Bit, aber nicht unter 32 Bit. Gibt es Probleme, wenn auf dem beiden PC komplett unterschiedliche Sprachen eingestellt sind, also auch mit vollständig anderem Zeichensatz?


Im Zusammennang mit 64 Bit habe ich noch eine Frage. Es wird ja überall empfohlen Option Explicit zu nutzen. Dann fehlen aber beim Compilieren die ganzen API-Konstanten, wie msoFileDialogFilePicker & Co.


Thomas

[markusxy]

Im Zusammennang mit 64 Bit habe ich noch eine Frage. Es wird ja überall empfohlen Option Explicit zu nutzen. Dann fehlen aber beim Compilieren die ganzen API-Konstanten, wie msoFileDialogFilePicker & Co.

Auf Option Explicit solltest du in keinem Fall verzichten.
Die Konstanten stehen doch in der Bibliothek.
Wenn der Verweis fehlt klappt das natürlich nicht.
Entweder Verweis verwenden, oder Late-Binding und Konstanten selbst deklarieren.

Gibt es Probleme, wenn auf dem beiden PC komplett unterschiedliche Sprachen eingestellt sind, also auch mit vollständig anderem Zeichensatz?

ja, kann es geben.
Da wird empfohlen in englisch zu entwickeln, hab da aber weniger Erfahrung, da ich das Problem nicht habe.

Du solltest hier konkrete Fehlermeldungen und den Code dazu zeigen.

[ThomasFtl]

Das ist der Inhalt des Moduls.

Code [Auswählen] Erweitern

Option Compare Database


#If Win64 Then
  Private Declare PtrSafe Function GetUserDefaultUILanguage Lib "kernel32.dll" () As Long
  Public Const Access64 = True
#Else
  Private Declare Function GetUserDefaultUILanguage Lib "kernel32.dll" () As Long
  Public Const Access64 = False
#End If


Public Sub setzeBeschriftung(FormName As String)
Dim rs As DAO.Recordset
Dim i As Integer
Dim ctr As Control
Dim UILang As Integer
Dim Kennung As String
Dim MaskenName As String



MaskenName = LCase(Forms(FormName).Name)
Kennung = Right(MaskenName, 3)

'Debug.Assert False

UILang = GetUserDefaultUILanguage()

Set rs = CurrentDb.OpenRecordset("beschriftung", dbOpenDynaset)
Do While Not rs.EOF
  If LCase(rs!maske) & Kennung = MaskenName Then
    If IsEmpty(rs!Label) Or IsNull(rs!Label) Then
      If UILang = 1049 Then
        Forms(FormName).Caption = rs!rus
      Else
        Forms(FormName).Caption = rs!deu
      End If
    Else
      For i = 0 To Forms(FormName).Controls.Count - 1
        Set ctr = Forms(FormName).Controls(i)
        If LCase(ctr.Name) = LCase(rs!Label) Then
          If UILang = 1049 Then
            ctr.Caption = rs!rus
          Else
            ctr.Caption = rs!deu
          End If
        End If
      Next i
    End If
  End If
  rs.MoveNext
Loop
rs.Close
Set rs = Nothing

End Sub

Im Formular steht dann:

Code [Auswählen] Erweitern

Private Sub Form_Load()
setzeBeschriftung Me.Name
End Sub
Es kommt die Meldung:

Sie haben als Einstellung der Ereigniseigenschaft den Ausdruck Bei Laden eingegeben. Dieser Ausdruck hat einen Fehler verursacht: Wärend der Kommunikation von Microsoft mit dem OLE-Server oder dem ActiveX-Steuerelement ist ein Problem aufgetreten.

Das Formular ist ein Endlosformular mit normalen Textboxen. Keine Comboboxen, keine Checkboxen oder andere Steuerelemente, bei denen man vermuten könnte, sie stammen aus irgendeiner System32-DLL und sind inkompatibel zwischen 32 Bit und 64 Bit.


Wenn es um die Sub aus dem Modul gehen würde, dann würde ja dort eine Fehlermeldung kommen.
Kann es sein, dass Formulare, die unter 32 Bit erstellt werden auch schon hart 32 Bit-Zeiger bekommen und Formulare unter 64 Bit einen 64 Bit-Zeiger? Anders kann ich mir nicht erklären, dass der Sub-Name (Formular_Load) angemeckert wird. Das passiert ja sonst nur, wenn die Parameterliste nicht stimmt.
Wenn ich im Formular noch Steuerelemente zur Filterung einbaue (z.B. Combobox mit Jahren) und dann eine entsprechende Sub aufrufe, um den Filter zu setzen, dann knallt es genauso, mit der gleichen Fehlermeldung. Daher meine Vermutung mit den Zeigern, die schon beim Anlegen der Formulare hart verdrahtet werden. Wenn ich im Nachgang den Code komplett entferne und neu eintrage, hilft das im übrigen auch nicht. Das Formular muss neu erstellt werden. Also, wenn ich ein Formular unter 32 Bit anlege, dann ist das Formular auf 32 Bit-Zeiger getrimmt und wenn ich das Formular unter 64 Bit anlege, dann steht schon von anfang an fest, dass alle Zeiger 64 Bit sind. Ich lasse mich gern eines besseren belehren, aber das ist erstmal das, was ich an meinem PC und am PC meiner Frau live sehe und erlebe.


Der Aufruf mit /Decompile hat nichts gebracht. Genauso wenig hilft, wenn man im VBA-Editor auf Debuggen --> Kompilieren geht oder auch die Datenbankreparatur aufruft.

Auf Option Explicit solltest du in keinem Fall verzichten.
Die Konstanten stehen doch in der Bibliothek.
Wenn der Verweis fehlt klappt das natürlich nicht.
Entweder Verweis verwenden, oder Late-Binding und Konstanten selbst deklarieren.

Wenn der Verweis zur Bibliothek fehlen würde, würde auch der Aufruf von Application.FileDialog fehlschlagen.

Ich schwitze zur Zeit an einem kleinen Projekt als Test. Momentan sind alle Formulare doppelt mit _32 und _64 am Ende des Namens, damit es überhaupt läuft und meine Frau damit arbeiten kann. Aber es liegt ein großes Projekt vor mir mit Anbindung an Outlook, Word und Excel und mit jeder Menge nicht Office-Steuerelementen (z.B. diverse TreeViews). Das Projekt ist in Backend unf Frontend getrennt. Die Backends sollen dann sowohl mit Acess 32 als auch mit Access 64 laufen. Und wenn schon so ein kleines frisch aufgesetztes 5 min-Projekt solche Probleme macht, ....


Thomas

[markusxy]

Kann es sein, dass Formulare, die unter 32 Bit erstellt werden auch schon hart 32 Bit-Zeiger bekommen und Formulare unter 64 Bit einen 64 Bit-Zeiger?

Nein, die Zeiger werden zur Laufzeit vom Betriebssystem generiert.

Das Problem hat soweit ersichtlich auch nichts mit dem Code zu tun.
Also wenn es in der Anwendung wirklich nur ein Formular gibt, ist der Fehler nicht erklärbar.
Du kannst ja gerne mal die Anwendung mit diesem einen Formular hochladen, dann könnte man das an einem anderen Rechner testen. Die Tabelle für die Übersetzung wird ja nicht unbedingt benötigt, kannst du aber auch gern mitliefern.
 

[markusxy]

Wenn der Verweis zur Bibliothek fehlen würde, würde auch der Aufruf von Application.FileDialog fehlschlagen.

Da sehe ich keinen Zusammenhang.
Die Konstanten sind in der Office Library definiert.
Ohne Verweis darauf, fehlt die Definition.

[ThomasFtl]

Das ist der Test. Das Formular Ausgaben_32 wurde unter Access 32 Bit angelegt. Es funktioniert auch nur da. Das Formular Ausgaben 64 ist das Äquivalent unter Access 64. Das 32 Bit Formular bringt einen Fehler unter 64 Bit und das 64-Bit Formular bringt den gleichen Fehler unter 32 Bit.
Wenn unter 32 Bit im 64-BitFormular den Aufruf im Load auskommentiere kommt der Fehler trotzdem. Erst, wenn ich die gesamte Load-Sub lösche, kommt kein Fehler mehr. Wenn ich dann unter Acess 32 im 64-Formular den Code wieder einfüge, kommt auch der Fehler wieder. Umgekehrt ist es unter Access 64 Bit mit dem 32 Bit Formular. Daher war meine Vermutung, dass die Pointerlängen beim Anlegen der Formulare festgeschrieben werden.

Oder es liegt daran, dass meine Frau Win 10 Prof und Office 365 auf russisch installiert hat und ich die deutsche Version habe. Der VBA-Editor ist da übrigens in englisch.


Thomas

[markusxy]

Ausgaben_32 wurde unter Access 32 Bit angelegt

Also bei mir funktioniert Ausgaben_32 sowohl unter 32 als auch unter 64 Bit.
Bei Ausgaben_64 bekomme ich immer die Fehlermeldung egal welche Bit-Version ich einsetze.

Irgendwie spannend die Angelegenheit.

[ThomasFtl]

Also anscheinend doch ein Problem der Sprache, wo man eigentlich davon ausgeht, dass intern alles englich ist. Aber es werden ja auch russischsprachige Namen vergeben, wenn man neue Steuerelemente im Formular anlegt. Vielleicht wird ja doch einiges intern in der Erstellungssprache gespeichert, anstatt in Englisch, auch wenn man alle Namen von Steuerelementen in Ansi vergibt.

[markusxy]

Also anscheinend doch ein Problem der Sprache, wo man eigentlich davon ausgeht, dass intern alles englich ist.

Hab jetzt mal die Formulare als Text exportiert.
Ja und da sind natürlich dann die internen Formularsektoren in russischer Sprache gehalten mit entsprechendem hinterlegtem CharSet.

Wie gesagt fehlt mir damit die Erfahrung, aber ich nehme mal an, es sollte User mit Kenntnissen in diesem Bereich geben.

[ThomasFtl]

Da lag ich mit meiner Vermutung gar nicht so falsch. Ich denke mal, das gehört in die große Kategorie "It´s not a bug. It´s Microsoft."

[markusxy]

Was ich weiß lautet die Empfehlung nur in englischer Sprachversion entwickeln.

Ansonsten kann ich nur zustimmen. Access ist mittlerweile eine Zumutung.
Alle drei Monate so schwere Bugs bei den monatlichen Updates, dass das Arbeiten vorübergehend nicht mehr möglich ist.
Aber so bleibt man in Bewegung.

[ThomasFtl]

Das setzt allerdings voraus, dass man sein Office in englisch installiert und nicht in seiner eigenen Sprache. Das geht am wirklichen Leben aber Lichtjahre vorbei, wie so vieles bei Winzigweich. Aber da können wir leider nichts ändern. Damit müssen wir leben. Also alles doppelt designen und den Quellcode kopieren.

Normalerweise mache ich nichts mehr in Access, außer ich brauche schnell mal was zusammengeschustertes mit ein paar Tabellen und ein paar kleinen Masken. Ansonsten mache ich Datenbankanwendungen seit 30 Jahren mit VFP, von dem es inzwischen sogar eine 64 Bit-Version und einen Nativ-Compiler (Umweg über Visual C++) gibt. Allerdings kommt es nicht mehr aus Redmont, sondern aus Shenzhen. Dafür sind aber extrem viele Fehler raus und die 2GB-Marke ist geknackt. Wenn ich noch was zusätzlich brauche, mache ich das mit C++. Das reicht mir für die nächsten 10 Jahre bis zum Ruhestand.

[PhilS]

Das setzt allerdings voraus, dass man sein Office in englisch installiert und nicht in seiner eigenen Sprache. Das geht am wirklichen Leben aber Lichtjahre vorbei, wie so vieles bei Winzigweich. Aber da können wir leider nichts ändern. Damit müssen wir leben. Also alles doppelt designen und den Quellcode kopieren.

Nun ja, ganz so ist es aber nicht.
1. Ist Office schon ewig Multilingual. D.h. die Sprache, in der du installierst, ist nur die Voreinstellung. Du kannst die Sprache von Office jederzeit umstellen (Options->Language).
2. Wie @markus888 bereits zutreffen analysiert hat, geht es wohl nur um die Namen der Formular- und Berichtsbereiche (Formular-/Seiten-Kopf/Fuß, Detail, +evtl. Gruppen im Bericht). Diese paar Steuerelementnamen kannst du mit wenigen Zeilen VBA automatisch ASCII kompatibel umbenennen.

Fazit: Ob das ganze ein Bug ist, kann man diskutieren. Unschön ist es auf jeden Fall. - Aber wenn man mit dem Problem rechnet, kann man es mit überschaubarem Aufwand umgehen.