Form And Report Washing PDF Drucken E-Mail

Zurückkonvertieren von Access 2007-Datenbanken in das Access 2002/3-Format

Sie mögen hin und wieder vor der Aufgabe stehen, eine Datenbank, die sie unter Access 2007 in dessen nativem Format (accdb) erstellt haben, in das Format für Access 2002 oder 2003 zu überführen, um sie auch früheren Versionen verfügbar zu machen.

Dazu wählen Sie im Office-Menü einfach den Menüpunkt Speichern unter | Access 2002-2003-Datenbank aus und speichern die Datenbank mit der Endung .mdb. Schon kann sie auch auf Rechnern, die etwa nur Access 2003 installiert haben, geöffnet werden.

Dass dabei Eigenschaften von Formularen und Steuerlementen verloren gehen, die es nur unter Access 2007 gibt - etwa Gestapeltes Layout, Verankerung oder der Textabstand für Steuerelemente -, ist klar, stört meist aber nicht weiter, weil diese Design-Features selten essentiell für Funktion und Gestalt der Formulare sind.

Und selbstverständlich dürfen auch andere Elemente von Access 2007, wie Anlagen und Anlagensteuerelemente, Richtext für Textboxen oder Tabellen, komprimierte Grafikspeicherung oder die Berichtsansicht nicht verwendet worden sein.

Sind diese Bedingungen erfüllt, dann steht dem Einsatz der MDB auch unter Access 2003 nichts mehr im Wege - sollte man denken.

 

Nun hat es sich allerdings gezeigt, dass solche rückkonvertierte Datenbanken zeitweilig instabil arbeiten oder sogar im Entwurfsmodus für Formulare und Berichte bei Änderungen Access 2003 abstürzen lassen. Besonders betroffen davon sind nach unserer Erfahrung Änderungen an Kombinationsfeldern.

Dass dies keine Lappalie ist, zeigte eine umfangreichere Access 2007-Datenbank, welche für den Einsatz unter Access 2003 umgebaut werden sollte. Es war praktisch unmöglich, die Formulare unter Access 2003 weiterzubearbeiten, weil es regelmäßig zu Abstürzen kam, wenn ein geänderter Formularentwurf gespeichert wurde.

Eher per Zufall stellte ich fest, dass es an Eigenschaften der Steuerelemente lag, die zwar im Eigenschaftenfenster nicht sichtbar sind, im Entwurf aber dennoch vorhanden. Ermitteln kann man dies, indem man ein Formular mit der versteckten Methode SaveAsText des Application-Objekts in Textform exportiert:

Application.SaveAsText acForm, "frmTest", "c:\testform.txt"

Beim Inspizieren des dergestalt exportierten Formulars, etwa mit Notepad, wird deutlich, dass Access 2007 alle Steuerelementeigenschaften, die unter Access 2003 nicht verfügbar sind, in Tags mit dem Ausdruck UnknownProp abgespeichert hat und dabei auch gleich die zugehörgen Parameter. Sinn des Ganzen ist, dass Access 2007 beim Laden dieser zurückkonvertierten MDB diese UnknownProps wieder erkennt und automatisch den entsprechenden A2007-Eigenschaften zuweist. Öffnet man also die MDB wieder mit Access 2007, dann sind wundersamerweise solche Features, wie Textabstand etc., wiederhergestellt.

Eigentlich eine sinnvolle Sache, wenn sie denn stabil funktionieren würde.

Um das Ganze zu verdeutlichen, ist in der folgenden Tabelle für ein Bezeichnungsfeld (Label) dargestellt, was der SaveAsText-Export ausgibt. In der ersten Spalte ist das Label direkt aus der ACCDB exportiert worden, die zweite Spalte zeigt, was daraus nach dem Konvertieren in das Access-2003-Format wird, und die letzte Spalte, wie der Label-Aufbau eigentlich unter A2003 aussehen sollte:

Aus Access 2007-Format (ACCDB) Nach Konvertierung ins Access 2003-Format Original Access 2003-Format
Begin Label
BackStyle =0
FontSize =11
FontName ="Calibri"
LeftPadding =30
TopPadding =30
RightPadding =30
BottomPadding =30
GridlineStyleLeft =0
GridlineStyleTop =0
GridlineStyleRight =0
GridlineStyleBottom =0
GridlineWidthLeft =1
GridlineWidthTop =1
GridlineWidthRight =1
GridlineWidthBottom =1
End

Begin Label
BackStyle =0
FontSize =11
FontName ="Calibri"
UnknownProp = {260 ,454 ,3 ,4 ,4 }
Begin
0x1e000000
End
UnknownProp = {261 ,455 ,3 ,4 ,4 }
Begin
0x1e000000
End
UnknownProp = {262 ,456 ,3 ,4 ,4 }
Begin
0x1e000000
End
UnknownProp = {263 ,457 ,3 ,4 ,4 }
Begin
0x1e000000
End
UnknownProp = {264 ,458 ,2 ,1 ,1 }
Begin
0x00
End
UnknownProp = {265 ,459 ,2 ,1 ,1 }
Begin
0x00
End
UnknownProp = {266 ,460 ,2 ,1 ,1 }
Begin
0x00
End
UnknownProp = {267 ,461 ,2 ,1 ,1 }
Begin
0x00
End
UnknownProp = {269 ,463 ,2 ,1 ,1 }
Begin
0x01
End
UnknownProp = {270 ,464 ,2 ,1 ,1 }
Begin
0x01
End
UnknownProp = {271 ,465 ,2 ,1 ,1 }
Begin
0x01
End
UnknownProp = {272 ,466 ,2 ,1 ,1 }
Begin
0x01
End
End

Begin Label
BackStyle =0
FontSize =11
FontName ="Calibri"
End


 

Das Interessante an der Geschichte: Entfernt man die UnknownProps aus den Formularexporten und reimportiert die Textdateien wieder mit der Methode Application.LoadFromText, dann arbeitet die Datenbank auch unter Access 2003 wieder stabil - die Abstürze verschwinden.

Ein Nebeneffekte ist außerdem, dass die Datenbank dadurch merklich schrumpft. Für das oben erwähnte Projekt bedeutete dies, dass sich die Größe der MDB von 8 MB auf nur 5 MB verringerte!

Der Washer

Doch wie stellt man es nun an, diese UnknownProps aus der MDB zu entfernen?

Alle Formulare und Berichte per SaveAsText zu exportieren und dann aus den Texten manuell akribisch alle UnknownProps-Abschnitte zu löschen, ist bei umfangreicheren Projekten wohl kein anstrebenswertes Unterfangen.

Deshalb musste eine Routine her, die den Vorgang automatisiert. Diese Routine finden Sie unten im Download.

Darin ist ein Modul enthalten, welches Sie folgendermaßen verwenden können:

  • Konvertieren Sie Ihre ACCDB in des Access 2003-Format
  • Öffnen Sie die nun erstellte MDB unter Access 2003
  • Importieren Sie im VBA-Editor die Datei mdlWasher.bas (Rechtsklick im Projektexplorer | Datei importieren... )
  • Führen Sie über das VBA-Direktfenster diese Anweisung aus: WashFormsReports
  • Die Prozedur wird ausgeführt und gibt am Schluss eine Zusammenfassung aus, ob und wieviele Formulare und Berichte einer Bereinigung von UnknownProps unterzogen wurden
  • Komprimieren Sie anschließend die Datenbank

Zur Sicherheit sollten Sie davor ein Backup der Datenbank vorgenommen haben. Kontrollieren Sie nach dem Washing, ob alle Formulare sowohl im Entwurf wie auch zur Laufzeit so funktionieren und aussehen, wie sie es sollten.

Die exportierten und bereingten Textdateien bleiben übrigens dabei im gleichen Verzeichnis, in dem sich die MDB befindet. Schauen Sie sich einfach interessehalber in einem Texteditor an oder löschen Sie sie wieder.

Was macht die Routine?

Zunächst werden alle Formulare und Berichte in Textform exportiert. Dann werden die Textdateien analysiert und ermittelt, ob sie überhaupt UnknownProp-Tags enthalten. Ist das der Fall, dann werden diese per String-Routinen entfernt und die Textdateien modifiziert abgespeichert.
Im letzten Schritt löscht die Prozedur nur jene Formulare und Berichte aus dem Projekt, die tatsächlich geändert werden mussten und reimportiert sie aus den entsprechenden Textdateien.

Bleibt noch zu bemerken, dass MDBs, die dieser Bereinigung unterzogen wurden, nun unter Access 2007 natürlich nicht mehr die ehemals gesetzten 2007er-Eigenschaften für Steuerelemente zeigen. Diese Eigenschaften (GridPadding & Co) sind dann auf Default-Werte eingestellt.

Für Datenbanken, die nur noch unter Access 2003 weiterentwickelt werden sollen, spielt das aber keine Rolle.

 

Sascha Trowitzsch, 11/2009

 

Download Washer-Modul

Melden Sie uns, falls sie mit der Prozedur Probleme haben oder es nicht korrekt funktioniert!

Update 12/2009: Nun gibt's die Routine auch eingebaut in ein Add-In; siehe hier...


 
Kommentare (10)
checksum
10 Dienstag, 09. März 2010 um 16:40 Uhr
Heli
Bei mir tritt dieses Problem auch auf.
Jedoch bei einer meiner eigenen Funktionen (LoadfromText).
Das Problem liegt in der Zeile CheckSum wenn im Txt.File was geändert wurde.
Aber nur mit einer Acc2003 Datenbank. Bei einer Acc2000 Datenbank besteht dieses Problem nicht.
Ich habe auch schon im Netz nach einer Lösung gesucht jedoch noch nichts gefunden.
Checksum
9 Dienstag, 09. März 2010 um 13:24 Uhr
Sascha Trowitzsch
Ach noch was:
Ich habe versucht, der Zeile Checksum = xyz auf die Schliche zu kommen.
Könnte ja sein, dass man diese Zahl neu berechnen muss, nachdem man den Text modifiziert hat.
Es ist mir jedoch nicht gelungen, das Verfahren herauszubekommen. Es scheint sich nicht um eine der üblichen CRC32-Algorithmen zu handeln.

Ciao, Sascha
RE: funktioniert bei mir leider nicht
8 Dienstag, 09. März 2010 um 13:18 Uhr
Sascha Trowitzsch
Von verschiedenen Seiten habe ich nun schon gehört, dass Access beim Aufruf von SaveAsText und/oder LoadFromText abstürzt.
Ich kann dazu leider nichts sagen - bei mir noch nie passiert - und ich fand auch bei Recherche nichts dazu im Netz.

Daher kann ich nur vorschlagen, den Code des Moduls zeilenweise ablaufen zu lassen. Wenn die Textdateien erstellt wurden, dann kann der Absturz wohl nur bei LoadFromText stattgefunden haben, also Haltepunkt auf diese Zeile setzen:

Application.LoadFromText acReport, CStr(itm), strFile

und danach mit F8 weitermachen.
Interessant wäre dann, ob es gleich beim ersten Aufruf von LoadFromText zum Absturz kommt, ode nur bei bestimmten Formular-Skripten.
Falls jemand das Ergebnis dann mitteilen möchte: Nur zu! (Unter Angabe der Version von Access; also das, was im Menü von Access unter ? > Info steht.)
Ansonsten sehe ich mir auch gern die Datenbanken an, die solche Abstürze beim Bereinigen hervorrufen. Einfach als ZIP an sascha_at_moss-soft_punkt_de schicken. Vertraulichkeit garantiert!

Gruß, Sascha
funktioniert bei mir leider nicht
7 Freitag, 05. März 2010 um 10:32 Uhr
Tom
Hallo,
also ich hab mir dieses Modul geladen und gestartet, nur leider stürzt mir Access immer ab bevor das Modul durch ist.
Die txt.Files werden zwar erstellt, an der DB ändert sich aber nichts.
Woran kann das liegen bzw wenn ich die unnötigen Zeilen selbst aus der txt Datei lösche, wie muss ich diese benennen/speichern um sie wieder in Acces importieren zu können?? (Add-In funktioniert auch nicht da ich kein Admin bin)
Danke
Re; FormWasher
6 Montag, 08. Februar 2010 um 21:28 Uhr
Sascha Trowitzsch
Hi Rolf,

Nun wäre interessant, ob dieser Fehler auch bei Benutzung des Moduls hier im Beitrag auftritt. Kannst du das evtl. mal checken?
Ist es die gleiche Zeile, wie bei Vladimir? (Application.LoadFromText ...)
Was ich an seiner Fehlermeldung nämlich eigenartig finde, ist das Objekt, welches JET nicht finden kann: ~sq_fTempSccObj1
Das ist nämlich definitiv die Datenherkunft eines Formulars. (SQL-Strings, die in die Eigenschaft Datenherkunft des Formulars eingegeben werden, sind in der versteckten Tabelle MSysObjects immer so dargestellt. "~" heißt nicht sichtbares Objekt, "sq" heißt Abfrage, "f" heißt Formular-SQL und dahinter steht der Name des Objekts, also das Formular "TempSccObj1".)
Wenn Vladimir hier noch mitspielen würde, dann würde ich ihn zunächst fragen, ob dieses Formular überhaupt funktioniert und die Datenherkunft korrekt ist.
Vielleicht reagiert LoadFromText allergisch auf Formularskripte, die nicht funkionierende Formulare ergäben...

Gruß, Sascha
FormWasher
5 Montag, 08. Februar 2010 um 19:52 Uhr
Rolf

Hallo Sascha, ich habe das formwasher-AddIn installiert und bekomme ähnliche Fehlermeldungen beim "Waschen" wie Vladimir.


Bei mir sucht die Jet-Engine das Objekt " und steigt aus.


Gruß Rolf

Änderung Checksum?
4 Dienstag, 08. Dezember 2009 um 19:27 Uhr
Sascha Trowitzsch
Hallo Vladimir,

Interessante Geschichte. Ich hatte natürlich auch Bedenken, ob man den Wert der Zeile Checksum nach Bearbeitung ds Formular-Scripts einfach so lassen kann, wie er davor dastand. Aber Probieren geht über Studieren und da es auch so in mehreren (!) Fällen funktionierte, hatte ich weiter keine Bedenken.
Es klappte sogar dann, wenn man die Checksum-Zeile komplett löscht! Vielleicht versuchst du das auch mal?
Hingegen darf der Wert für Version und VersionRequired nicht höher sein, als 19. Mit 20, wie es etwa beim Export aus Access 2007 geschieht, schlägt der Import fehl. Das bedeutet, dass die Routine zwingend unter Access 2003 ausgführt werden muss. Kann es sein, dass du aus Access 2007 exportiert hast?
Ansonsten hatte ich so eine JET-Fehlermeldung noch nie. Falls das Script etwa nach manueller Bearbeitung fehlerhaft war, dann kamen schon Meldungen, aber nur diese beiden:
"Die Operation wurde abgebrochen." und
"Die Ausgabedatei konnte nicht erstellt werden."

Ciao, Sascha
Ich habe Pech, statt Begeisterung, Enttäuschung…
3 Donnerstag, 03. Dezember 2009 um 17:19 Uhr
Vladimir
Wenn ich mit dieser Routine oder per Hand in beliebige exportierte Datei etwas ändere (einzige Buchstabe genügt(!), dass ich die ganze Teile „UnknowProp = …“ entferne, davon kann ich nur träumen) führt dass im Programmschritt
Application.LoadFromText acForm, CStr(itm), strFile
zur Meldung
„Run-time error ‚3011‘. DB Maschine Microsoft Jet kann Objekt ~sq_fTempSccObj1 nicht finden. Überprüfen Sie, ob das Objekt existiert und ob Sie richtigen Weg und Name eingegeben haben.” (frei übersetzt aus Tschechischen).
Vielleicht ist an der Schuld die 3 Zeile in der exportierte Datei:
Checksum = -446427867 (zum Beispiel)
Wenn ich zum Beispiel nur letzte Ziffer in Checksum ändere, führt das zum Fehler.
Wenn ich diese Ziffer zurückgebe, kann ich dieselbe Datei problemlos einlesen.
Wieso läuft das bei anderen Problemlos? Ich bin ratlos. Gibt es vielleicht eine Hilfe (Kontrolsumme nach Änderungen erneut errechnen?)
Vielen Dank für eventuelle Hilfe, mindestens für etwas Trost…
PS:
Quelle: A2007 (12.0.6423.1000) SP2 MSO, Windows Vista Business 6.0.6002 SP2
Ziel: A2003 (11.8166.8172) SP3, Windows XP Professional5.1.2600 SP3
Thanks!
2 Mittwoch, 02. Dezember 2009 um 23:28 Uhr
Sascha Trowitzsch
Danke für das Feedback, Georg.
Das ist wichtig, denn umso mehr dieses eigentümliche Verhalten von Access 2003 (?) bestätigen können, desto größer die Chance, dass auch MS sich des Problems mal in Form eines Service Packs oder Hotfix annimmt.
Immerhin haben mir die Abstürze und die Lösung des Problem damals locker einen Tag zusätzliche Arbeit verschafft...

Denkbar wäre auch, dass MS für Access 2007/2010 eine Option vorsieht, die wahlweise bei Konvertierung den Export der UnknownProps erlaubt oder herausfiltert. Das wäre an sich die sinnvollste Lösung.

Gruß, Sascha
Form And Report Washing
1 Mittwoch, 02. Dezember 2009 um 18:04 Uhr
Georg
Hallo Sascha,
das ist genial. Ich habe eine Anwendung unter A2003 laufen, die mit A2007 entwickelt und konvertiert wurde. Ich bekam bei fast jeder kleinen Änderung am Formular Abstürze, bzw. wurde teilweise das Form kompl. zerschossen. Jetzt habe ich das nochmal analysiert, und siehe da - genau das war das Problem.
Besten Dank,
Georg

Ihren Kommentar hinzufügen

Ihr Name:
Betreff:
Kommentar:
  Bild, welches den Sicherheitscode enthält
Sicherheitscode: