Discussion:
MDB-Version ermitteln aus binary
(zu alt für eine Antwort)
Thomas Winkler
2009-11-10 16:10:56 UTC
Permalink
Hallo allerseits,

wie kann man aus einer MDB-Datei die Format-Version ermitteln? Ich
brauche eine Lösung die "von außen", d. h. ohne Access die Version
ermitteln kann.

Habe da an das binäre Auslesen eines/einiger Bytes aus dem MDB-Header
gedacht - nur weis ich weder wie der Header aufgebaut ist, noch an
welcher Position die MDB-Version zu finden ist.

Könnt Ihr mir da weiterhhelfen?

Thomas
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Sascha Trowitzsch
2009-11-10 20:38:50 UTC
Permalink
Post by Thomas Winkler
Hallo allerseits,
wie kann man aus einer MDB-Datei die Format-Version ermitteln? Ich
brauche eine Lösung die "von außen", d. h. ohne Access die Version
ermitteln kann.
Habe da an das binäre Auslesen eines/einiger Bytes aus dem MDB-Header
gedacht - nur weis ich weder wie der Header aufgebaut ist, noch an
welcher Position die MDB-Version zu finden ist.
Könnt Ihr mir da weiterhhelfen?
Ich kann dir nur mit einer ADO-Routine helfen, die z.B. auch per VB-Script
ausgeführt werden könnte:

Function GetMDBVersion(strDB As String) As String
Dim oConx As Object

Set oConx = CreateObject("ADODB.Connection")
oConx.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source="
& strDB
oConx.Open
GetMDBVersion = oConx.Properties("Jet OLEDB:Engine Type")
oConx.Close
End Function

Ciao, Sascha
Thomas Winkler
2009-11-16 09:14:24 UTC
Permalink
Hallo Sascha,
Post by Sascha Trowitzsch
Ich kann dir nur mit einer ADO-Routine helfen, die z.B. auch per
Function GetMDBVersion(strDB As String) As String
Dim oConx As Object
Set oConx = CreateObject("ADODB.Connection")
oConx.ConnectionString = "Provider=Microsoft.Jet.OLEDB.4.0;Data
Source=" & strDB
oConx.Open
GetMDBVersion = oConx.Properties("Jet OLEDB:Engine Type")
oConx.Close
End Function
Das Projekt ist in Java geschrieben und der Zugriff auf die MDB erfolgt
über die JDBC-ODBC-Brücke. Das erzeugte java.sql.Connection-Object
verfügt zwar über einige Methoden um die Eigenschaften der Connection
auszulesen (getMetaData()), den "Engine Type" allerdings konnte ich
nicht finden - wohl aber die JET Version.

Danke trotzdem.

Thomas
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Jens Schilling
2009-11-10 20:44:01 UTC
Permalink
Hallo, Thomas
Post by Thomas Winkler
wie kann man aus einer MDB-Datei die Format-Version ermitteln? Ich
brauche eine Lösung die "von außen", d. h. ohne Access die Version
ermitteln kann.
Schau mal, ob Dir dies hilft:

http://msdn.microsoft.com/en-us/library/aa139959%28office.10%29.aspx

Dort kannst Du zum Download die ODC_AcFormat.exe finden, die widerum eine
mdb enthält, die mdbs und adps aus Verzeichnissen nach dem DB-Format als
Bericht auflistet.

Vielleicht hilfts Dir ja ....
--
Gruss
Jens

FAQ: http://www.donkarl.com
Thomas Winkler
2009-11-11 17:23:30 UTC
Permalink
Hallo Jens,
Post by Jens Schilling
Vielleicht hilfts Dir ja ....
In der Tat. Vielen Dank.

Der Code...

Const VERSION_STRING_SIZE As Integer = 24
Const JET_2_VERSION_NUMBER_START As Integer = 1
Const JET_VERSION_NUMBER_START As Integer = 21
Const LENGTH As Integer = 1

Open strDB_file For Binary As lngSource
strData = Space(VERSION_STRING_SIZE)
Get #lngSource, , strData
Close lngSource

If Chr(1) = Mid(strData, JET_2_VERSION_NUMBER_START, LENGTH) Then
theVersion = "Microsoft Access 2"
ElseIf Chr(0) = Mid(strData, JET_VERSION_NUMBER_START, LENGTH) Then
theVersion = "Microsoft Access 97"
ElseIf Chr(1) = Mid(strData, JET_VERSION_NUMBER_START, LENGTH) Then
theVersion = "Microsoft Access 2000/2002"
Else
theVersion = "Unable to determine the version " & _
"of database file"
End If

funktioniert und kann A2, A97 und A2000/A2002 DBs auseinander halten.

Allerdings fehlt mir nun noch A2k3 und A2k7. Hat da jemand noch paar infos?

Danke.

Thomas
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Sascha Trowitzsch
2009-11-11 18:02:21 UTC
Permalink
Hi Thomas,
Post by Thomas Winkler
Hallo Jens,
Post by Jens Schilling
Vielleicht hilfts Dir ja ....
In der Tat. Vielen Dank.
Der Code...
Const VERSION_STRING_SIZE As Integer = 24
Const JET_2_VERSION_NUMBER_START As Integer = 1
Const JET_VERSION_NUMBER_START As Integer = 21
Const LENGTH As Integer = 1
Open strDB_file For Binary As lngSource
strData = Space(VERSION_STRING_SIZE)
Get #lngSource, , strData
Close lngSource
If Chr(1) = Mid(strData, JET_2_VERSION_NUMBER_START, LENGTH) Then
theVersion = "Microsoft Access 2"
ElseIf Chr(0) = Mid(strData, JET_VERSION_NUMBER_START, LENGTH)
Then theVersion = "Microsoft Access 97"
ElseIf Chr(1) = Mid(strData, JET_VERSION_NUMBER_START, LENGTH)
Then theVersion = "Microsoft Access 2000/2002"
Else
theVersion = "Unable to determine the version " & _
"of database file"
End If
funktioniert und kann A2, A97 und A2000/A2002 DBs auseinander halten.
Allerdings fehlt mir nun noch A2k3 und A2k7. Hat da jemand noch paar infos?
Was ist mit dem Code aus meinem anderen Post?
Ich benutze den selbst. Er kann nur A2000 und A2003-Formate nicht
unterscheiden.
A2000 ist's aber dann, wenn die Tabelle MSysAccessObjects existiert. ;-)

Das oben ist mir nicht klar: Was soll A2000/A2002 sein?
A2000 ist ungleich A2002 ...

Ciao, Sascha
Jens Schilling
2009-11-11 18:18:14 UTC
Permalink
Hallo, Sascha
Post by Sascha Trowitzsch
Das oben ist mir nicht klar: Was soll A2000/A2002 sein?
A2000 ist ungleich A2002 ...
Ich hab' grad noch mal nachgeschaut - es wird nur die Jet-Version
imterpretiert:

Zitat:
[...] the first 24 bytes of the header of each file to determine the
version of Jet used to create the file. From this, we infer the version of
Access that created the current file.
--
Gruss
Jens

FAQ: http://www.donkarl.com
Josef Poetzl
2009-11-11 18:48:35 UTC
Permalink
Hallo!
Post by Jens Schilling
Ich hab' grad noch mal nachgeschaut - es wird nur die Jet-Version
[...] the first 24 bytes of the header of each file to determine the
version of Jet used to create the file. From this, we infer the version of
Access that created the current file.
Ich probierte ein wenig mit Database-Properties herum.
Interessant sind vermutlich Version und AccessVersion

Meine Testergebnisse:
Version 3.0 + AccessVersion 07.53 = Ac97
Version 4.0 + AccessVersion 08.50 = Ac2000
Version 4.0 + AccessVersion 09.50 = Ac2002 (2003)
Version 12.0 + AccessVersion 09.50 = Ac2007

Version steht für die Jet- bzw. ACE-Version.
Aber kann mir jemand erklären, was die Eigenschaft "AccessVersion"
aussagen soll? Ich bin ursprünglich davon ausgegangen, dass das jene
Version ist, aus der die mdb erstellt wurde bzw. als ersten geöffnet
wurde. Wenn man eine mdb/accdb nur über die DBEngine erstellt, fehlt
nämlich diese Eigenschaft.
Warum steht aber bei einer accdb, die ich mit Ac2007 erstellte, eine 9
wie bei AcXP?


mfg
Josef
--
EPT: (Access Error Prevention Table) http://access.joposol.com/
FAQ: (Access-FAQ von Karl Donaubauer) http://www.donkarl.com/
Thomas Winkler
2009-11-12 07:45:02 UTC
Permalink
Hallo Sascha,
Post by Sascha Trowitzsch
Was ist mit dem Code aus meinem anderen Post?
Ich benutze den selbst. Er kann nur A2000 und A2003-Formate nicht
unterscheiden.
Ich habe ihn leider noch nicht ausprobieren können. Das kommt aber noch
und ich berichte hier.
Post by Sascha Trowitzsch
Das oben ist mir nicht klar: Was soll A2000/A2002 sein?
A2000 ist ungleich A2002 ...
Es wird nur die JET-Version ausgewertet und diese ist für A2k und A2k2
gleich. Darum können diese nicht ohne Weiteres unteschieden werden.

Jetzt bin ich dabei das "ohne Weiteres" zu klären.
Post by Sascha Trowitzsch
A2000 ist's aber dann, wenn die Tabelle MSysAccessObjects existiert. ;-)
Also unterscheidet die Existenz dieser Tabelle 2k von 2k2 oder 2k/2k2
von 2k3? Oder anders: ist diese Tabelle *nur* bei A2k vorhanden?

Danke.

Thomas

BTW: Das ganze fließt in ein OpenSource Projekt zum DB-Management
(ReverseEngineering, Design, Migration, ERD, etc...) ein. Demnächst
gibt's ein Release mit experimentellem Access-Support. Ist es hier
erwünscht, zu verkünden, wann es soweit ist?
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Henry Habermacher
2009-11-12 07:58:23 UTC
Permalink
Hallo Thomas
Post by Thomas Winkler
Post by Sascha Trowitzsch
A2000 ist's aber dann, wenn die Tabelle MSysAccessObjects existiert. ;-)
Also unterscheidet die Existenz dieser Tabelle 2k von 2k2 oder 2k/2k2
von 2k3? Oder anders: ist diese Tabelle *nur* bei A2k vorhanden?
Migrierst Du eine 2k MDB nach 2k2 und wieder zurück nach 2k bleibt (oder
zumindest blieb damals) die MSysAccessObjects bestehen.

Gruss
Henry
--
Microsoft MVP Office Access
Keine E-Mails auf Postings in NGs. Danke.
Access FAQ www.donkarl.com
Thomas Winkler
2009-11-12 08:50:33 UTC
Permalink
Hallo,
Post by Henry Habermacher
Migrierst Du eine 2k MDB nach 2k2 und wieder zurück nach 2k bleibt (oder
zumindest blieb damals) die MSysAccessObjects bestehen.
Gestestet unter A2k2:

MDB erstellt: standardmäßig im 2k-format
-> MSysAccessObjects vorhanden

nach 2k2-format konvertiert:
-> MSysAccessObjects *nicht* vorhanden

wieder zurück nach 2k-format
-> MSysAccessObjects wieder vorhanden

Thomas
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Henry Habermacher
2009-11-13 01:20:05 UTC
Permalink
Hallo Thomas
Post by Thomas Winkler
Post by Henry Habermacher
Migrierst Du eine 2k MDB nach 2k2 und wieder zurück nach 2k bleibt (oder
zumindest blieb damals) die MSysAccessObjects bestehen.
MDB erstellt: standardmäßig im 2k-format
-> MSysAccessObjects vorhanden
-> MSysAccessObjects *nicht* vorhanden
wieder zurück nach 2k-format
-> MSysAccessObjects wieder vorhanden
Kann durchaus sein, dass das später noch geändert wurde. Ich bin ganz
sicher, das war nicht immer so, kann aber dann auch ein Fehler gewesen sein.
Ich hatte damals nämlich untersucht, wieso eine zurück konvertierte MDB, die
vorher fast leer war, nach dem Zurückkonvertieren nicht wieder die
Originalgrösse angenommen hat und dann eben diese Tabelle gefunden, die dann
aber unter A2k nicht mehr geschützt war und weggeputzt werden konnte.

Gruss
Henry
--
Microsoft MVP Office Access
Keine E-Mails auf Postings in NGs. Danke.
Access FAQ www.donkarl.com
Gerald Aichholzer
2009-11-12 08:09:33 UTC
Permalink
Hallo Thomas,
Post by Thomas Winkler
(ReverseEngineering, Design, Migration, ERD, etc...) ein. Demnächst
gibt's ein Release mit experimentellem Access-Support. Ist es hier
erwünscht, zu verkünden, wann es soweit ist?
arbeitest du an diesem Projekt weiter:
http://sourceforge.net/projects/mdbtools/

Falls nicht, schau mal rein - vielleicht findest du dort
etwas Brauchbares.

lG,
Gerald
Thomas Winkler
2009-11-12 08:18:38 UTC
Permalink
Hallo Gerald,
Post by Gerald Aichholzer
http://sourceforge.net/projects/mdbtools/
Nein, es ist nicht mdbtools. :-)
Post by Gerald Aichholzer
Falls nicht, schau mal rein - vielleicht findest du dort
etwas Brauchbares.
Danke für den Hinweis. Aber dort hatte ich schon nachgeguckt und nichts
gefunden.

THX

Thomas
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Sascha Trowitzsch
2009-11-12 14:12:48 UTC
Permalink
Hi,
Post by Thomas Winkler
Hallo Gerald,
Post by Gerald Aichholzer
http://sourceforge.net/projects/mdbtools/
Nein, es ist nicht mdbtools. :-)
Post by Gerald Aichholzer
Falls nicht, schau mal rein - vielleicht findest du dort
etwas Brauchbares.
Danke für den Hinweis. Aber dort hatte ich schon nachgeguckt und
nichts gefunden.
Naja, ich hab den C-Quellcode für die MDBTOOLS, der in leicht geänderter
Form auch von Kexi verwendet wird.
( http://www.freshports.org/databases/keximdb/ ) Bringt aber nix.
Es ist kein Wunder, dass beide Projekte eingeschlafen sind, weil sich
niemand die Mühe machte, die ursprünglich von Brian Burns (in 2000)
erstellte Version weiterzuentwickeln und auf die neueren Access-Formate
auszudehnen. ;-)

Ciao, Sascha
Thomas Winkler
2009-11-12 08:53:20 UTC
Permalink
Hallo,
Post by Thomas Winkler
Also unterscheidet die Existenz dieser Tabelle 2k von 2k2 oder 2k/2k2
von 2k3? Oder anders: ist diese Tabelle *nur* bei A2k vorhanden?
Die Frage konnte ich mir jetzt selbst beantworten. In den Versionen
*vor* 2k2 (getestet bis A97) gibt's die MSysAccessObjects. In 2k2 ist
sie nicht mehr vorhanden - auch wenn man dorthin *konvertiert*.

Das bringt mich auf die Idee die späteren Versionen anhand ihrer
MSys*-Tabellen zu unterscheiden. Kann mir mal bitte jemand alle
MSys*-Tabellen einer mit A2k7 neu erstellten ACCDB nennen (habe kein A2k7)?

THX

Thomas
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Gunter Avenius
2009-11-12 09:14:27 UTC
Permalink
Hallo Thomas,

Thomas Winkler schrieb folgendes:
...
Post by Thomas Winkler
Kann mir mal bitte jemand alle
MSys*-Tabellen einer mit A2k7 neu erstellten ACCDB nennen (habe kein A2k7)?
MSysAccessStorage
MSysACEs
MSysComplexColumns
MSysNavPaneGroupCategories
MSysNavPaneGroups
MSysNavPaneGroupToObjects
MSysNavPaneObjectIDs
MSysObjects
MSysQueries
MSysRelationships

Gruß
Gunter
--
__________________________________________________________
Access FAQ: http://www.donkarl.com

home: http://www.avenius.com - http://www.AccessRibbon.de
http://www.ribboncreator.de

12. Access-Entwickler-Konferenz (AEK)
Nürnberg 10./11.10.2009 und 31.10/1.11.2009
http://www.donkarl.com/?AEK
Thomas Winkler
2009-11-12 09:23:21 UTC
Permalink
Hallo Gunter,
Post by Gunter Avenius
MSysAccessStorage
MSysACEs
MSysComplexColumns
MSysNavPaneGroupCategories
MSysNavPaneGroups
MSysNavPaneGroupToObjects
MSysNavPaneObjectIDs
MSysObjects
MSysQueries
MSysRelationships
Vielen Dank für die Liste. 2k7 kann ich also anhand der
MSysComplexColumns unterscheiden. Könntest Du mir bitte noch eine leere,
frisch erstellte 2007er ACCDB zum download bereitstellen damit ich mir
das ganze nochmal binär zu Gemüte führen kann?

THX

Thomas
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Gunter Avenius
2009-11-12 09:42:52 UTC
Permalink
Hallo Thomas,
Post by Thomas Winkler
Vielen Dank für die Liste. 2k7 kann ich also anhand der
MSysComplexColumns unterscheiden. Könntest Du mir bitte noch eine leere,
frisch erstellte 2007er ACCDB zum download bereitstellen damit ich mir
Tabellen in A2007 leere Datenbanken:

accdb:
MSysAccessStorage
MSysACEs
MSysComplexColumns
MSysNavPaneGroupCategories
MSysNavPaneGroups
MSysNavPaneGroupToObjects
MSysNavPaneObjectIDs
MSysObjects
MSysQueries
MSysRelationships

mdb 2002/2003:
MSysAccessStorage
MSysACEs
MSysNavPaneGroupCategories
MSysNavPaneGroups
MSysNavPaneGroupToObjects
MSysNavPaneObjectIDs
MSysObjects
MSysQueries
MSysRelationships

mdb 2000:
MSysAccessObjects
MSysACEs
MSysNavPaneGroupCategories
MSysNavPaneGroups
MSysNavPaneGroupToObjects
MSysNavPaneObjectIDs
MSysObjects
MSysQueries

Link für Datenbanken:
http://www.file-upload.net/download-2005959/Dbs.zip.html

Gruß
Gunter
--
__________________________________________________________
Access FAQ: http://www.donkarl.com

home: http://www.avenius.com - http://www.AccessRibbon.de
http://www.ribboncreator.de

12. Access-Entwickler-Konferenz (AEK)
Nürnberg 10./11.10.2009 und 31.10/1.11.2009
http://www.donkarl.com/?AEK
Thomas Winkler
2009-11-12 10:05:21 UTC
Permalink
Hallo Gunter,
Post by Gunter Avenius
http://www.file-upload.net/download-2005959/Dbs.zip.html
Sauber! Das is ja mehr als ich erhoffte. :-)

BTW: Anhand der MSysNavPane*-Tabellen kann man auch erkennen dass die
MDBs mit A2k7 erstellt wurden. Die Fehlen nämlich mei mir.

Thomas
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Josef Poetzl
2009-11-12 10:45:33 UTC
Permalink
Hallo!
Post by Thomas Winkler
BTW: Anhand der MSysNavPane*-Tabellen kann man auch erkennen dass die
MDBs mit A2k7 erstellt wurden. Die Fehlen nämlich mei mir.
Da wäre ich etwas vorsichtig bzw. würde zumindest "erstellt" auf
"geöffnet" ändern. ;-)

Die "blanke" ACE-DB (mit DBEngine.CreateDatabase erstellt) enthält nur
die Tabellen:
MSysACEs
MSysComplexColumns
MSysObjects
MSysQueries
MSysRelationships

Die MSysNavPane*-Tabellen kommen dazu, wenn man die DB mit Ac07
öffnet.

mfg
Josef
--
EPT: (Access Error Prevention Table) http://access.joposol.com/
FAQ: (Access-FAQ von Karl Donaubauer) http://www.donkarl.com/
Gunter Avenius
2009-11-12 11:46:42 UTC
Permalink
Hallo,
Post by Josef Poetzl
Die MSysNavPane*-Tabellen kommen dazu, wenn man die DB mit Ac07
öffnet.
... oder mit der Access GUI erstellt ;-)

Gruß
Gunter
--
__________________________________________________________
Access FAQ: http://www.donkarl.com

home: http://www.avenius.com - http://www.AccessRibbon.de
http://www.ribboncreator.de
Sascha Trowitzsch
2009-11-12 14:18:17 UTC
Permalink
Hi,
Post by Jens Schilling
Hallo,
Post by Josef Poetzl
Die MSysNavPane*-Tabellen kommen dazu, wenn man die DB mit Ac07
öffnet.
... oder mit der Access GUI erstellt ;-)
...und außerdem bleiben sie bestehen, wenn man nach A2003/3
runterkonvertiert. ;-)
Das ist also kein verlässliches Kriterium.

Ich insistiere auf meinem oben geposteten Code!
Connection.Properties("Jet OLEDB:Engine Type")
gibt für eine A97er 4 zurück, für A2000 ff. die 5 und für A2007 eine 6.
Den Rest kann man über die MSys-Tabellen ermitteln.

Ciao, Sascha
Henry Habermacher
2009-11-13 01:41:09 UTC
Permalink
Hallo Gunter
Post by Gunter Avenius
...
Post by Thomas Winkler
Kann mir mal bitte jemand alle
MSys*-Tabellen einer mit A2k7 neu erstellten ACCDB nennen (habe kein A2k7)?
MSysAccessStorage
MSysACEs
MSysComplexColumns
MSysNavPaneGroupCategories
MSysNavPaneGroups
MSysNavPaneGroupToObjects
MSysNavPaneObjectIDs
MSysObjects
MSysQueries
MSysRelationships
Bevor wir hier auf Holzwege geführt werden: Wenn jemand eine MDB mittels
DAO/Jet erstellt, also ohne Access, fehlen da ettliche der genannten
Tabellen (das war schon seit Versionen so). Diese werden von Access
hinzugefügt, wenn die MDB das erste mal mit Access geöffnet werden. Access
macht das, um da drin seine Objekte abzulegen. Jet alleine hat mit den
Access Objekten eigentlich gar nichts am Hut, für Jet sind das Tabellen, wie
andere Benutzerdefinierte Tabellen. Und diese legt eben dann Access an.

Hier ein einfaches VB-Script:
Option Explicit
Dim daoObject
Dim db
Dim strMsg
Dim I
Const conDBName = "~$TEST$~.mdb"
On Error Resume Next
Set daoObject = CreateObject("DAO.DBEngine.36")
Set db = daoObject.OpenDatabase(conDBName, _
False, False)
if Err Then
Err.Clear
Set db = daoObject.CreateDatabase(conDBName, _
";LANGID=0x0409;CP=1252;COUNTRY=0")
End If
If Err Then
MsgBox Err.Description
End If
strMsg = Null
For I = 0 To db.TableDefs.Count - 1
strMsg = (strMsg + Chr(13) & Chr(10)) & _
db.TableDefs(I).Name
Next
MsgBox strMsg, , "Systemobjekte"
db.Close
Set db = Nothing
Set daoObject = Nothing

Ergebnis:
DAO.DBEngine.36 legt folgende Tabellen an:
MSysACEs
MSysObjects
MSysQueries
MSysRelationships

Nach dem Öffnen mit Access 2007 und nochmaligem Starten des Scripts sind da
zusäztlich:
MSysAccessStorage
MSysNavPaneGroupCategories
MSysNavPaneGroups
MSysNavPaneGroupToObjects
MSysNavPaneObjectIDs

angelegt worden. Es ist also nicht möglich, anhand der Tabellen die Frage
des OPs im Subject zu beantworten. Mit dem anschauen der MSysAccess... oder
MSysNav... Objekte findet man also nur raus, welche Access Version da
verwendet worden ist, nicht welche MDB-Version es ist.

Gruss
Henry
--
Microsoft MVP Office Access
Keine E-Mails auf Postings in NGs. Danke.
Access FAQ www.donkarl.com
Thomas Winkler
2009-12-07 10:35:44 UTC
Permalink
Hallo an alle Interessierten,
Post by Thomas Winkler
BTW: Das ganze fließt in ein OpenSource Projekt zum DB-Management
(ReverseEngineering, Design, Migration, ERD, etc...) ein. Demnächst
gibt's ein Release mit experimentellem Access-Support. Ist es hier
erwünscht, zu verkünden, wann es soweit ist?
Da es keine Gegenstimmen gibt, erlaube ich mir das angesprochene Release
zu verkünden:

Mogwai ERDesignerNG v2.5.0 steht jetzt unter

http://sourceforge.net/projects/mogwai/

zum Download zur Verfügung.


Bugreports bitte unter
http://sourceforge.net/tracker/?atid=510777&group_id=65384&func=browse
posten.

Feature Requests bitte unter
http://sourceforge.net/tracker/?atid=510780&group_id=65384&func=browse
posten.

Thomas
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Siegfried Schmidt
2009-12-07 14:40:28 UTC
Permalink
Post by Thomas Winkler
Da es keine Gegenstimmen gibt, erlaube ich mir das angesprochene
Das sieht wirklich gut aus.

Gibts für den Export der Gesamtansicht eine Größenbeschränkung? Ich bekomme
bei einem Projekt nur Bilder mit Länge Null.


Siegfried
Thomas Winkler
2009-12-07 15:00:57 UTC
Permalink
Hallo Siegfried,
Post by Siegfried Schmidt
Das sieht wirklich gut aus.
Gibts für den Export der Gesamtansicht eine Größenbeschränkung? Ich bekomme
bei einem Projekt nur Bilder mit Länge Null.
Welches Bildformat hast Du gewählt?
Wieviele Tabellen hast Du?

Bisher sind keine solche Probleme bekannt. Allerdings gib's
Bildbetrachter (IrfanView, GIMP), die mit der SVG-Anzeige manchmal
Probleme haben. Das erzeugte SVG ist aber fehlerfrei und wird dann auch
von InkScape ordentlich angezeigt.

Thomas
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Siegfried Schmidt
2009-12-07 22:25:49 UTC
Permalink
Post by Thomas Winkler
Welches Bildformat hast Du gewählt?
Bei png, jpg, bmp und svg der gleiche Effekt.
Post by Thomas Winkler
Wieviele Tabellen hast Du?
250 Tabellen, 50 Views, 450 Fremdschlüssel-Constraints

Mit einigen wenigen Tabellen gehts.
Post by Thomas Winkler
Bisher sind keine solche Probleme bekannt. Allerdings gib's
Bildbetrachter (IrfanView, GIMP), die mit der SVG-Anzeige manchmal
Probleme haben. Das erzeugte SVG ist aber fehlerfrei und wird dann
auch von InkScape ordentlich angezeigt.
Betrachter scheidet aus, die Dateien sind definitiv leer. Das Programm
rechnet beim Export einige Zeit bis es wieder ansprechbar ist, bringt aber
keine Fehlermeldung.

Siegfried
Thomas Winkler
2009-12-07 23:22:07 UTC
Permalink
Hallo Siegfried,
Post by Siegfried Schmidt
Post by Thomas Winkler
Wieviele Tabellen hast Du?
250 Tabellen, 50 Views, 450 Fremdschlüssel-Constraints
Na das is schon eine ganz schöne Menge - aber sollte kein Grund für ein
Problem sein. Getestet wird ständig und auch an solchen Giganten.

Welches DBMS benutzt Du? Der Access-Support ist derzeit noch in einem
sehr frühen Stadium und daher auch als "experimentell" gekennzeichnet.
Produktiv einsetzbar ist es noch nicht. Wir arbeiten gerade am Auslesen
von MDBs. Wenn dass läuft wird auch deren Weiterverarbeitung in Angriff
genommen.
Post by Siegfried Schmidt
Betrachter scheidet aus, die Dateien sind definitiv leer. Das Programm
rechnet beim Export einige Zeit bis es wieder ansprechbar ist, bringt aber
keine Fehlermeldung.
OK. Gibt's in der Konsole einen Stacktrace? Dann öffne bitte einen Bug
im genannten Bugtracker und füge den Stacktrace mit ein. Wenn möglich,
bitte auch ein als MXM-gespeichertes Datenmodell. Das vereinfacht das
Nachvollziehen ungemein. Wenn Du ein Problem damit hast, dein Modell im
öffentlichen Tracker zu posten, kann ich Dir auch eine Mail-Adresse geben.

HTH

Thomas
Siegfried Schmidt
2009-12-09 16:20:43 UTC
Permalink
Post by Thomas Winkler
Na das is schon eine ganz schöne Menge - aber sollte kein Grund für
ein Problem sein. Getestet wird ständig und auch an solchen Giganten.
Es gibt einen Heap-Überlauf beim Exportieren. Erst dachte ich dass es an
der Anzahl der Objekte liegt, tatsächlich ist der Fehler aber nur von der
Darstellungsgrösse abhängig, d.h. bei vielen Tabellen ist er durch
Rücknahme des Zoomfaktors vermeidbar (dass letzteres für den Export eine
Rolle spielt sollte vielleicht in der Doku deutlich stehen).
Post by Thomas Winkler
OK. Gibt's in der Konsole einen Stacktrace? Dann öffne bitte einen Bug
im genannten Bugtracker und füge den Stacktrace mit ein. Wenn möglich,
bitte auch ein als MXM-gespeichertes Datenmodell. Das vereinfacht das
Nachvollziehen ungemein. Wenn Du ein Problem damit hast, dein Modell
im öffentlichen Tracker zu posten, kann ich Dir auch eine Mail-Adresse
geben.
Ich muss noch etwas experimentieren...


Siegfried
Thomas Winkler
2009-12-09 18:52:41 UTC
Permalink
Hallo Siegfried,
Post by Siegfried Schmidt
Es gibt einen Heap-Überlauf beim Exportieren. Erst dachte ich dass es an
der Anzahl der Objekte liegt, tatsächlich ist der Fehler aber nur von der
Darstellungsgrösse abhängig, d.h. bei vielen Tabellen ist er durch
Rücknahme des Zoomfaktors vermeidbar (dass letzteres für den Export eine
Rolle spielt sollte vielleicht in der Doku deutlich stehen).
Also eine bekannte Beschränkung gibt es nicht. Dabei handelt es sich
wohl um einen bisher unbekannten Bug. Die Lösung wird also nicht in
einer Erweiterung der Doku liegen, sondern in einem Bugfix. :-)

Thomas

Thomas Winkler
2009-11-16 10:23:52 UTC
Permalink
Hallo allerseits,

zuerst einmal vielen Dank für die vielen Tips und Hinweise.

Ich muss mein Problem wohl nocheinmal etwas klarer formulieren, da ich
selbst nicht ausreichend zwischen binärem Auslesen und der Verwendung
einer Connection differenziert habe.

Hauptanliegen ist es, die MDB-Version *ohne* das Herstellen einer
Verbindung zu ermitteln. D. h. es muss anhand verschiedener Bit- oder
Byte-Muster (möglichst exakt) erkannt werden, um welche MDB-Version es
sich handelt. Bisher ist mir das so direkt noch nicht gelungen.

Einzig die zum Erstellen der MDB genutzte JET/ACE-Engine kann ich bisher
ermitteln und damit (recht ungenau) die MDB-Version "schätzen". Damit
lässt sich folgendes ermitteln:

Jet 2 -> 2.0
Jet 3 -> 97
Jet 4 -> 2000, 2002 oder 2003
ACE -> 2007

Nun bleiben nach Ermittlung der Jet Version zwei Unsicherheiten:
- Was ist mit Access 95?
- Wie halte ich die 200X-Versionen auseinander?

Wenn sich nun A2000 von den 2002/2003-er dadurch unterscheidet, dass
eine Tabelle "MSysAccessObjects" existiert, könnte man diesen String in
der MDB-Datei suchen. Damit hätte man im Idealfall 2000 erkannt.

Man müsste aber im WorstCase 2GB durchsuchen, was nicht gerade
performant ist. Gibt es irgendwo ein Offset, ab dem im binary die
Tabellen(namen) aufgelistet werden? Die Frage läuft letztendlich auf
eine Format-Beschreibung hinaus. Kennt jemand soetwas?

Was ist aber, wenn in einer 2002er ein beliebiges Objekt mit diesem
Namen per Hand anlegt? Wie halte ich 2002 und 2003 auseinander?

Kann mir vielleicht noch jemand eine leere A95 oder/und A2.0 MDB
zukommen lassen und deren MSys*-Tabellen nennen?

Danke.

Thomas
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Sascha Trowitzsch
2009-11-16 13:25:17 UTC
Permalink
Hi Thomas,
Post by Thomas Winkler
Hallo allerseits,
zuerst einmal vielen Dank für die vielen Tips und Hinweise.
Ich muss mein Problem wohl nocheinmal etwas klarer formulieren, da ich
selbst nicht ausreichend zwischen binärem Auslesen und der Verwendung
einer Connection differenziert habe.
Hauptanliegen ist es, die MDB-Version *ohne* das Herstellen einer
Verbindung zu ermitteln. D. h. es muss anhand verschiedener Bit- oder
Byte-Muster (möglichst exakt) erkannt werden, um welche MDB-Version es
sich handelt. Bisher ist mir das so direkt noch nicht gelungen.
Einzig die zum Erstellen der MDB genutzte JET/ACE-Engine kann ich
bisher ermitteln und damit (recht ungenau) die MDB-Version
Jet 2 -> 2.0
Jet 3 -> 97
Jet 4 -> 2000, 2002 oder 2003
ACE -> 2007
- Was ist mit Access 95?
- Wie halte ich die 200X-Versionen auseinander?
Wenn sich nun A2000 von den 2002/2003-er dadurch unterscheidet, dass
eine Tabelle "MSysAccessObjects" existiert, könnte man diesen String
in der MDB-Datei suchen. Damit hätte man im Idealfall 2000 erkannt.
Man müsste aber im WorstCase 2GB durchsuchen, was nicht gerade
performant ist. Gibt es irgendwo ein Offset, ab dem im binary die
Tabellen(namen) aufgelistet werden? Die Frage läuft letztendlich auf
eine Format-Beschreibung hinaus. Kennt jemand soetwas?
Was ist aber, wenn in einer 2002er ein beliebiges Objekt mit diesem
Namen per Hand anlegt? Wie halte ich 2002 und 2003 auseinander?
Das allerdings hättest du ruhig schon früher erwähnen können, dass es sich
um Java handelt...
Aber auch das reicht mir noch nicht, um das Vorhaben wirklich zu verstehen:
Auf welcher Plattform soll das laufen?
Falls Windows: Welche OS-Versionen sollen unterstützt werden?
Oben sprichst du von JDBC-Bridge, hier von Auslesen ohne jegliche
Connection; was jetzt? Ist ODBC erlaubt?

Ich habe im Netz noch keinerlei Informationen zum MDB/ACCDB-Format gefunden,
das neuer, als von 2001 wäre - und das reicht hier nicht.
Insofern wirst du selbst forschen müssen, wenn du rein binär auslesen
willst, wobei mir sowas, wie einfach nur nach Strings der Tabellennamen zu
suchen, nicht ausreichend erscheint.
Falls das Ganze unter Windows laufen soll, verstehe ich aber immer noch
nicht, warum man kein ADO-Connection-Objekt verwenden kann. Das geht doch
auch mit Java?

Mit A2.0/95-DBs kann ich leider nicht dienen.

Ciao, Sascha
Thomas Winkler
2009-11-16 13:58:56 UTC
Permalink
Hallo Sascha,
Post by Sascha Trowitzsch
Das allerdings hättest du ruhig schon früher erwähnen können, dass es
sich um Java handelt...
Sorry. Meinte ursprünglich, das wäre egal.
Post by Sascha Trowitzsch
Auf welcher Plattform soll das laufen?
Falls Windows: Welche OS-Versionen sollen unterstützt werden?
Das Programm läuft auf allen Platformen und nur auf Windows OSen auch
Access anbieten. Das ganze soll auch (möglichst) unabhängig von der
Windows-Version sein - d. h. die aktuellen (ab 2k) sollten schon
funktionieren.
Post by Sascha Trowitzsch
Oben sprichst du von JDBC-Bridge, hier von Auslesen ohne jegliche
Connection; was jetzt? Ist ODBC erlaubt?
Das Programm liest/schreibt natürlich Tabellen über eine Connection
(JDBC-ODBC-Bridge) aus/in die MDB und nicht binär. :-)

Nur wenn der Rechner kein MDAC, Jet, kein Office 2007 etc installiert
hat, scheitert das Aufbauen einer Connection mit einem nichtssagenden
Fehler. In diesem Falle soll die MDB "geparst" werden und der Benutzer
zur Installation der passenden Engine mit einem Link dazu aufgefordert
werden.
Post by Sascha Trowitzsch
Ich habe im Netz noch keinerlei Informationen zum MDB/ACCDB-Format
gefunden, das neuer, als von 2001 wäre - und das reicht hier nicht.
Insofern wirst du selbst forschen müssen, wenn du rein binär auslesen
willst, wobei mir sowas, wie einfach nur nach Strings der Tabellennamen
zu suchen, nicht ausreichend erscheint.
Das reicht mir eben auch nicht weils ziemlich fehleranfällig ist.
Post by Sascha Trowitzsch
Falls das Ganze unter Windows laufen soll, verstehe ich aber immer noch
nicht, warum man kein ADO-Connection-Objekt verwenden kann. Das geht
doch auch mit Java?
Denke schon. Aber IMHO ist doch auch für die ADO-Connection die
entsprechende Engine nötig, oder irre ich da? D. h. zu dem Zeitpunkt zu
dem ich die ADO-Connection einsetzen würde ist eigentlich schon klar,
dass es nichts wird. :-(

Danke.

Thomas
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Henry Habermacher
2009-11-17 05:00:27 UTC
Permalink
Hallo Thomas
Post by Thomas Winkler
Nur wenn der Rechner kein MDAC, Jet, kein Office 2007 etc installiert
hat, scheitert das Aufbauen einer Connection mit einem nichtssagenden
Fehler. In diesem Falle soll die MDB "geparst" werden und der Benutzer
zur Installation der passenden Engine mit einem Link dazu aufgefordert
werden.
Wieso muss es die passende Engine sein? Selbst die ACE ist doch backward
kompatibel und kann IIRC selbst Jet3 (oder Jet 2.5) MDBs bearbeiten, oder
täusche ich mich?
Post by Thomas Winkler
Denke schon. Aber IMHO ist doch auch für die ADO-Connection die
entsprechende Engine nötig, oder irre ich da? D. h. zu dem Zeitpunkt zu
Siehe oben

Gruss
Henry
--
Microsoft MVP Office Access
Keine E-Mails auf Postings in NGs. Danke.
Access FAQ www.donkarl.com
Thomas Winkler
2009-11-17 08:10:02 UTC
Permalink
Hallo Henry,
Post by Henry Habermacher
Wieso muss es die passende Engine sein? Selbst die ACE ist doch backward
kompatibel und kann IIRC selbst Jet3 (oder Jet 2.5) MDBs bearbeiten,
oder täusche ich mich?
Ich dachte, ACE wäre abwärts bis Jet 4 kompatibel. Darunter bräuchte man
Jet <= 4. Aber Du verunsicherst mich jetzt und ich nehme das zum
Anlass nochmal genauer nachzuforschen.

THX

Thomas
--
"Access? Damit arbeite ich nicht. Das ist doch nur ein abgespecktes Excel."
Loading...