MDB-Version ermitteln aus binary
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.
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
> 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
Jens Schilling
Thomas Winkler wrote:
> 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
Thomas Winkler
> 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.
Sascha Trowitzsch
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
Sascha Trowitzsch wrote:
> 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.
Josef Poetzl
Jens Schilling schrieb:
> 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.
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
> 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.
> 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.
> 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?
Henry Habermacher
Thomas Winkler wrote:
>> 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
Gerald Aichholzer
Thomas Winkler wrote:
> (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
> arbeitest du an diesem Projekt weiter:
> http://sourceforge.net/projects/mdbtools/
Nein, es ist nicht mdbtools. :-)
> 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
Thomas Winkler
> 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
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
Gunter Avenius
Thomas Winkler schrieb folgendes:
...
> 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
> 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?
Gunter Avenius
Thomas Winkler schrieb folgendes:
> 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
Thomas Winkler
> Link f�r Datenbanken:
> 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.
Josef Poetzl
Thomas Winkler schrieb:
> 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.
Gunter Avenius
Josef Poetzl schrieb folgendes:
> Die MSysNavPane*-Tabellen kommen dazu, wenn man die DB mit Ac07
> �ffnet.
... oder mit der Access GUI erstellt ;-)
Sascha Trowitzsch
Thomas Winkler wrote:
> Hallo Gerald,
>
>> arbeitest du an diesem Projekt weiter:
>> http://sourceforge.net/projects/mdbtools/
>
> Nein, es ist nicht mdbtools. :-)
>
>> 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
Sascha Trowitzsch
Gunter Avenius wrote:
> Hallo,
>
> Josef Poetzl schrieb folgendes:
>> 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
Thomas Winkler wrote:
>> 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
>
> nach 2k2-format konvertiert:
> -> 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.
Henry Habermacher
Gunter Avenius wrote:
> Thomas Winkler schrieb folgendes:
> ...
>> 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.
Thomas Winkler
> 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
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 Winkler
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.
Sascha Trowitzsch
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
> 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.
> 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?
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.
> 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.
> 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.
> 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. :-(
Henry Habermacher
Thomas Winkler wrote:
> 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?
> 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
Thomas Winkler
> 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 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
Siegfried Schmidt
> Da es keine Gegenstimmen gibt, erlaube ich mir das angesprochene
> Release zu verkï¿œnden:
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
> 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.
Siegfried Schmidt
> Welches Bildformat hast Du gewï¿œhlt?
Bei png, jpg, bmp und svg der gleiche Effekt.
> Wieviele Tabellen hast Du?
250 Tabellen, 50 Views, 450 Fremdschlï¿œssel-Constraints
Mit einigen wenigen Tabellen gehts.
> 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
>> 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.
> 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
> 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).
> 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
> 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