Access Datenbank auf neuem PC kaputt

[sugar76]

Hallo,

eine von mir entwickelte Access-DB macht auf einem neuen PC Probleme: einige Formulare lassen sich nicht mehr öffnen und in der VBA-Ansicht werden ungültige Zeichen angezeigt (siehe Screenshot).

Auf beiden PCs – alt und neu – ist das aktuelle MS Office 365 installiert.

Ich habe die ACCDB-Datei per USB-Stick kopiert und dann nochmal die Datei über OneDrive vom alten PC gezogen - beide Male derselbe Fehler.

Die Datei scheint in Ordnung zu sein: ich habe sie testweise auf einen dritten PC kopiert, dort läuft's einwandfrei.

Das Problem liegt also wahrscheinlich auf dem neuen PC und nicht in der ACCDB-Datei.

Kennt jemand das Problem bzw. hat eine Idee, wie ich den Fehler beheben kann?

Gruß 

[Knobbi38]

Hallo Sugar,

die VBE kann grundsätzlich nur ANSI-Zeichen darstellen und alle andere Zeichen werden dann zwangsweise so wie in deinem Screenshot dargestellt.

Normalerweise gehören die dt. Umlaute zum ANSI-Zeichensatz, sollten also richtig angezeigt werden. Möglicherweise sind sie aber mal durch UNICODE- oder UTF-8 Zeichen ungewollt ersetzt worden?

Einfach die Zeichen mit den richtigen Zeichen überschreiben, dann sollte es das gewesen sein.

Knobbi38

[PhilS]

Normalerweise gehören die dt. Umlaute zum ANSI-Zeichensatz

Im Kontext der Zugehörigkeit von bestimmten Zeichen gibt es nicht "den ANSI-Zeichensatz"!
ANSI arbeitet mit Codepages, die einen Zeichensatz für einen jeweils bestimmten Sprachraum definieren. Für Microsoft's ANSI Implementierung wird die Codepage 1252 für die USA und West Europa verwendet.

In Windows gibt es in der Systemsteuerung (Region \ Administrative) die Möglichkeit die "Sprache für Nicht-Unicode-Programme" (o.ä.) einzustellen. Dieses bestimmt indirekt, welche Codepage die VBA Umgebung verwendet.
Wenn durch diese Einstellung eine Codepage gewählt wurde, die nicht unsere Umlaute enthält, können diese nicht dargestellt werden und wenn sie im VBA-Programmcode vorkommen, lässt sich der Code evtl. nicht mehr kompilieren.

Also, @sugar76, schau mal nach welche Sprache für deinen Computer in der Systemsteuerung -> Region ->  Administrative eingestellt ist.

[Bitsqueezer]

Hallo,

und u.a. darum gehören Umlaute grundsätzlich nicht in Objektnamen. Man darf bezweifeln, daß MS alle möglichen Nebeneffekte in allen Sprachen der Welt testet. Access/Office "spricht" halt nativ Englisch. Zum Glück ist MS nicht auch noch auf die Idee gekommen, SQL in Deutsch zu übersetzen...

Da man nicht immer weiß, in welcher Sprache eine Anwendung ausgeführt wird, verzichtet man besser auf alles Regionale. Ich hatte noch nie solche Probleme, weil ich auch die Windows-Systemsprache und Office-Sprache grundsätzlich auf Englisch einstelle. (Verhindert u.a. auch schräge Übersetzungen in SSMS für SQL Server.)

Allerdings hatte ich so einen Darstellungsfehler im Projektexplorer auch noch nicht...

Gruß

Christian

[Knobbi38]

@PhilS:

Normalerweise gehören die dt. Umlaute zum ANSI-Zeichensatz

Sicherlich hast du Recht, wenn du schreibst, daß es den ANSI-Zeichensatz eigentlich nicht gibt und sich diese auf einigen Positionen unterscheiden, den sogenannten Codepages. Deshalb habe ich auch von "normalerweise" gesprochen, denn hierzulande darf man, wenn nichts anderes explizit erwähnt wird, davon ausgehen, daß eine dt. Windowsversion mit dt. regionalen Einstellungen installiert ist, ansonsten dürfte das auch in anderen Programmen bereits aufgefallen sein.

Das aber der VBA-Sourcecode beim Öffnen einer Anwendung auf einer Maschine mit anderen regionalen Einstellungen automatisch verändert wird, bezweifel ich dann aber doch sehr stark. Lediglich die Anzeige dürfte davon betroffen sein.

Viel interessanter finde ich in diesem Zusammenhang, daß der Fehler im Projektexplorer auftritt, also bei den Modul- und Klassenbezeichnungen.
Würde mich mal interessieren, was im Attribut "VB_NAME" beim Export einer solchen Datei steht. Könnte damit auch die Objektnamen-Autokorrektur damit etwas zu tun haben?

Gruß Ulrich


Nachtrag:
Du könntest mit deinem Hinweis bezügl. den Regionseinstellungen recht haben. Eventuell ist das Häkchen bei "Beta: Unicode UTF-8 für die Unterstützung weltweiter Sprachen" gesetzt. Ich meine, daß hätte bei mir auch schon mal Schwierigkeiten in der VBE verursacht.

[PhilS]

[...] davon ausgehen, daß eine dt. Windowsversion mit dt. regionalen Einstellungen installiert ist, ansonsten dürfte das auch in anderen Programmen bereits aufgefallen sein.

Da die meisten modernen Programme Unicode unterstützen, fällt das eben u.U. gar nicht auf, ausser in der VBA-Umgebung, wenn man eine andere Sprache/Codepage für die Nicht-Unicode-Programme eingestellt hat.

Das aber der VBA-Sourcecode beim Öffnen einer Anwendung auf einer Maschine mit anderen regionalen Einstellungen automatisch verändert wird, bezweifel ich dann aber doch sehr stark. Lediglich die Anzeige dürfte davon betroffen sein.

Die gespeicherten Bytes des Programmcodes werden natürlich nicht verändert. Aber wie diese Bytes dann als Text interpretiert werden, sowohl in der visuellen Darstellung als auch bei der Verarbeitung durch den VBA-Kompiler, kann sich abhängig von der aktiven Codepage sehr wohl ändern.

Und es bleibt dabei: die VBE kann nur Zeichen des ANSI-Zeichensatzes, also 8-Bit Character um genau zu sein, darstellen, egal welche Codepage eingestellt ist und als Ersatzzeichen wird immer dieses schwarze Viereck mit dem Fragezeichen verwendet.

Vermutlich meinen wir dasselbe, deine Formulierung erscheint mir jedoch missverständlich.
Die VBA-Umgebung stellt den Programmcode in der aktuellen Codepage dar, auch wenn der Code ursprünglich geschrieben wurde, als eine anderen Codepage aktiv war.

[PhilS]

Den Nachtrag sehe ich jetzt erst...

Nachtrag:

Du könntest mit deinem Hinweis bezügl. den Regionseinstellungen recht haben. Eventuell ist das Häkchen bei "Beta: Unicode UTF-8 für die Unterstützung weltweiter Sprachen" gesetzt. Ich meine, daß hätte bei mir auch schon mal Schwierigkeiten in der VBE verursacht.

Dieses "Beta: Unicode UTF-8"-Häckchen ist mir eben erstmalig aufgefallen. - Dass es evtl. zusätzliche Probleme verursacht will ich nicht ausschließen.

Auch ohne das Häckchen können die hier beschriebenen Probleme bei abweichenden Einstellungen für die Sprache der Nicht-Unicode-Programme auftreten. - Das ist keine reine Spekulation meinerseits, ich habe das so bereits mehrfach beobachtet.

[Knobbi38]

@PhilS:

Wir meinen sicherlich das gleiche, nur eben anders ausgedrückt. 

Ich bin mit aber ziemlich sicher, daß ich mit diesem Häkchen "Beta ..." und VBA mal Probleme hatte und das sehr schnell wieder deaktiviert habe. Deshalb möchte ich das auch nicht mehr ohne Not ausprobieren ...

Grüße Ulrich

[PhilS]

Mal so als allgemeine Info noch zwei Screenshots von ein und derselben Ereignisprozedur in VBA. 
Der erste auf einem Rechner mit cp1251:
Sie dürfen in diesem Board keine Dateianhänge sehen.
Die Ereignisprozedur (Button_Click) lässt sich auf diesem Rechner einwandfrei ausführen.

Der zweite mit 1252 als ANSI-Codepage:
Sie dürfen in diesem Board keine Dateianhänge sehen. 
Der Code kann zwar kompiliert werden, aber beim Klick auf den Button passiert nichts. Vermutlich schon deshalb nicht, weil die Verbindung zwischen dem Button in der Ereignisprozedur über den Namen nicht mehr hergestellt werden kann.

Wenn man eine ACCDE mit der obigen Prozedur mit cp1251 kompiliert und dann auf einem Rechner mit cp1252 den Button klickt, kommt es zu folgender Fehlermeldung:

The expression On Click you entered as the event property setting produced the following error: A problem occurred while Microsoft Access was communicating With the OLE server or ActiveX Control.

• The expression may not result in the name of a macro, the name of a user-defined function, or [Event Procedure].
• There may have been an error evaluating the function, event, or macro.

Würde mich mal interessieren, was im Attribut "VB_NAME" beim Export einer solchen Datei steht.

Auf dem Rechner mit cp1251: Attribute VB_Name = "Form_Форма1"
 Auf dem Rechner mit cp1252: Attribute VB_Name = "Form_?????1"

[Knobbi38]

Hallo Phil,

danke für deine Bemühungen und Rückmeldung.

Klar ist, daß die Zeichen gemäß der jeweiligen Codepage angezeigt werden, weil es alles 8 Bit Zeichen sind, nur das es eben für jeden Hex-Wert anders dargestellt wird. Auch kann man erkennen, daß der VBA-Code selber nicht verändert wird. 

Interessant in diesem Zusammenhang die Fehlermeldung. Offensichtlich berücksichtigt eine interne Komponente die Codepage, während andere das nicht machen. Wenn die Codepage nur die Anzeige ändern würde, dürfte es beim kompilieren ja eigentlich keine Fehler geben, denn die Codepage gilt ja für den gesamten VBA-Code und der eigentliche Hexcode wird ja dabei nicht verändert.

Ich glaube aber nicht, daß das etwas mit dem ursprünglichem Problem zu tun hat. Ich kenne die Anzeige des Vierecks mit Fragezeichen nur in Verbindung mit Problemen mit UNICODE Zeichen und tippe immer noch auf diese "Beta ..." Einstellung. Bei falscher Codepage-Einstellung dürfte eher so ein Bild, wie in deinem Screenshot zu sehen war, angezeigt werden.

Mal schauen, was der OP zurückmeldet.

Grüße Ulrich
 

[PhilS]

Interessant in diesem Zusammenhang die Fehlermeldung. Offensichtlich berücksichtigt eine interne Komponente die Codepage, während andere das nicht machen.

Das dürfte korrekt sein.
Die reine Access-Umgebung unterstützt Unicode. Access möchte in meinem Beispiel die Ereignisprozedur кнопку0_Click ausführen. Die VBA-Runtime kennt aber dann nur êíîïêó0_Click und somit passt dann auch der Teil der Fehlermeldung: The expression may not result in the name of a macro, the name of a user-defined function, or [Event Procedure].

Ich glaube aber nicht, daß das etwas mit dem ursprünglichem Problem zu tun hat. Ich kenne die Anzeige des Vierecks mit Fragezeichen nur in Verbindung mit Problemen mit UNICODE Zeichen und tippe immer noch auf diese "Beta ..." Einstellung. Bei falscher Codepage-Einstellung dürfte eher so ein Bild, wie in deinem Screenshot zu sehen war, angezeigt werden.

An das Fragezeichen in der Raute kann ich mich im Moment auch nicht konkret erinnern. Deine Vermutung könnte also zutreffend sein.

[Knobbi38]

FWIW:

https://de.wikipedia.org/wiki/Ersetzungszeichen

[sugar76]

Etwas verspätet ... vielen Dank für die Tipps, es lag an den Umlauten. Habe diese mühsam entfernt (aus allen Tabellen, Abfragen, Formularen, VBA Funktionen) und jetzt geht es wieder