Aus MS Access Datenbankverknüpfung auf .dbf Dateien

[Magic]

Hallo Forengemeinde,

ich habe direkt mit dem Advantage Data Architekt (V. 8.0) neue Tabellen erzeugt (DATABASE => TABLES => CREATE). Index ist CDX, einige Tabellen enthalten auch Memo Felder.
Jetzt versuche ich die Tabellen unter MS Access (V. 2003 SP3) zu verknüpfen (Tabellen => Tabellen verknüpfen …).
Egal welches Format ich verwende (dbaseIII bis dbaseV, per ODBC) scheitert das Verknüpfen. Ich erhalte die Fehlermeldung: „Die externe Tabelle hat nicht das erwartete Format“.

Wo liegt denn das Problem? Wo muss ich suchen & ggf. korrigieren?

Viele Grüße,
Magic

[Tom]

Hallo, Magic.

Sinnvoll ist nur das Dateiformat "dBASE III", die beiden anderen waren Erweiterungen, die aber nicht von Xbase++ oder dem DA unterstützt werden. dBASEIII hat aber gewisse Einschränkungen, etwa die mögliche Anzahl Felder usw. Wichtig wäre auch, dass die Datei tatsächlich für DBFNTX erzeugt wurde, und nicht etwa für Fox, auch da gibt es nämlich Unterschiede (mal vom Memo-Format abgesehen - DBT vs. FPT). Ich kann "echte" 3er-Dateien jedenfalls problemlos importieren und verknüpfen, also solche Tabellen (selbst mit Memo), die sich auch tatsächlich noch mit dBaseIII öffnen lassen, aber bei solchen z.B. mit sehr vielen Feldern meldet Access bei mir auch, dass es nicht geht.

[Magic]

Hallo,

an der Anzahl Felder wird es wohl nicht liegen. Es geht hier um 5 Tabellen mit 5 - 15 Feldern.
Die Memodatei hat die Endung .FPT.

Wichtig wäre auch, dass die Datei tatsächlich für DBFNTX erzeugt wurde, und nicht etwa für Fox

Frage mich gerade, wie ich das bestimmen kann?
Muss noch mal in die Dokumentation von Advantage Data Architect schauen ob ich da etwas finde.
Eine Auswahlmöglichkeit habe ich beim Erzeugen jedenfalls nicht.

Gruß,
Magic

[Tom]

Die Memodatei hat die Endung .FPT.

Fox. Das kann der Access-Importer nicht.

[brandelh]

Hallo Magic,

das erste Byte einer DBF bestimmen das Format, 0x03 = DBase III, ohne Memo, 0x30 Foxpro etc.
Siehe hierzu meinen Beitrag http://www.xbaseforum.de/viewtopic.php? ... &hilit=dbf

ABER wenn eine FPT Datei da ist, ist es immer eine Foxpro Datei. Die kann M$ Excel nicht lesen (vermutlich Access auch nicht) !
EINE DBT steht für DBFNTX Dateien (dBase 3), solange man selbst die Endungen der Memodatei nicht geändert hat.

[Magic]

Fox. Das kann der Access-Importer nicht.

Schade. Schön währe es gewesen.
Jetzt muss ich wohl meinen Plan verwerfen.

Allerdings habe ich mich noch nie so genau mit den Formaten beschäftigt.
Wenn ich 'ne Tabelle brauche, dann läge ich sie über den Advantage D.A. an.
Habe mir nie Gedanken über die Memofelder (.FPT / .DBT) gemacht.

Jetzt mal eine Frage ohne vorher darüber nachgedacht zu haben
Geht eigentlich CDX mit DBFNTX? Wohl nicht würde ich mal so spontan sagen.
Ist ja schließlich auch DBFNTX und nicht DBFCDX.
Richtig? Bin gerade ein wenig verwirrt

[Tom]

Geht eigentlich CDX mit DBFNTX? Wohl nicht würde ich mal so spontan sagen.

Klar geht das, viele nutzen DBF mit CDX. Du musst nur die DBE "bauen". Such mal nach "DBFCDX" im Forum (steht aber, glaube ich, sogar in der Doku). Ich habe allerdings keine Ahnung, ob der Data Architect da mitmacht.

[brandelh]

Hi Magic,

du solltest die DBE Grundlagen lesen

DBFDBE (DATA) + NTXDBE (Index) => DBFNTX // Standard Clipper
DBFDBE (DATA) + CDXDBE (Index) => DBFCDX // geht ist aber ungewöhnlich (Memo bleibt DBT)
FOXDBE (DATA) + CDXDBE (Index) => FOXCDX // hat viele Vorteile, insbesondere bei Memofeldern,
aber Excel etc. können das nicht lesen (DBF über ODBC ?)

Ein FoxPro ODBC Treiber eventuell ?

[Magic]

du solltest die DBE Grundlagen lesen

Stimmt! Man fängt ja auch nicht beim Hausbau mit dem Dach an ...

Ich habe allerdings keine Ahnung, ob der Data Architect da mitmacht.

Habe mal auf die Schnelle die Doku von Advantage D.A. durchgeschaut und folgendes ist mir aufgefallen:

The Advantage Database Server supports standard Xbase DBF tables that are compatible with CA-Clipper DBF tables, Microsoft FoxPro DBF tables.

-> musst doch gehen?

Advantage stores data for Xbase memo fields in DBT and FPT memo file formats depending on which Advantage database driver was used to open the corresponding table. When using the Advantage NTX driver, DBT memo files are supported. For FPT memos, the Advantage CDX driver must be used.

-> mit DBT wird wohl nix, da ausschließlich der CDX Treiber genutzt wird

[Jan]

-> mit DBT wird wohl nix, da ausschließlich der CDX Treiber genutzt wird

Das Eine hat mit dem Anderen nix zu tun. DBT ist die Clipper-Version des Memofeldes, CDX der Fox-Index. Kann man ganz wunderbar miteinander kombinieren.

Jan

[brandelh]

-> mit DBT wird wohl nix, da ausschließlich der CDX Treiber genutzt wird

wenn sich diese Aussage auf die "Advantage Datenbanktreiber" bezieht, weiß ich es nicht,
für Xbase DBEs hingegen hat JAN völlig Recht.

[Tom]

Am Rande bemerkt: Wenn ich das richtig verstehe, sollen von der Xbase++-Applikation Tabellen erzeugt und verwaltet werden, die zugleich in Access verknüpft sind und dort benutzt werden. Wenn man so etwas machen will, sollte man sich mit dem Konzept von Access intensiv auseinandersetzen. Für den konkurrierenden Betrieb (Locking!) werden dort propreitäre Mechanismen benutzt, die äußerst wahrscheinlich nicht mit denjenigen von Xbase++ kompatibel sind. Um das wiederum sicherzustellen, müsste die Xbase++-Applikation auf ihre "nativen" Dateien über die ODBC zugreifen, ansonsten wird's meiner Meinung nach früher oder später knallen. Ganz zu schweigen von der Index-Verwendung, die Access überhaupt nicht unterstützt. Chaos quasi (und im Sinn des Wortes) vorprogrammiert.

[AUGE_OHR]

... Ganz zu schweigen von der Index-Verwendung, die Access überhaupt nicht unterstützt. Chaos quasi (und im Sinn des Wortes) vorprogrammiert.

wenn ich den Thread bis hier richtig verfolgt habe will "Magic" mittels Access auf "laufende" DBF Daten zugreifen ...
vielleicht auch noch mit Excel ...
Wenn das ein User bei mir "versuchen" würde, gäbe es "Haue" dafür

nicht nur das Index Dateien nicht "upgedatet" werden sondern auch "was" Access oder Excel in einer DBF "verändern" ist solchen Usern unbekannt.
schon das gemeinsame verwenden von "Cl*pper" und Xbase++ DBFDBE ( OEM ) Dateien und NTX Index Dateien ist nicht ganz einfach,
aber M$ Produkte arbeiten mit ANSI ...

bei FOXDBE hast du zwar ANSI aber "gewöhnlich" werden die mit "CDXDBE" benutzt.
CDX Indexe werden aber "gewöhnlich" automatisch mit der DBF "geöffnet" ... aber nur wenn die "passen"

ein Anzeichen das was nicht "stimmt" ist das Datum / Uhrzeit. Hierbei meine ich "LastAccessTime" nicht "LastWriteTime".

also liebe Access / Excel & Co Programmierer : Finger weg von den DBF Dateien.

wenn man mit einem "anderen" Programm "kommunizieren" will sollte man das über eine Import/Export Routine tun,
aber auf gar keinen Fall "direkt" auf eine DBF auf die auch "andere" zugreifen "könnten"
( p.s. Im/Ex DBF nach Gebrauch löschen und immer mit Cl*pper/Xbase++ neu erstellen )

[Magic]

Guten Morgen,

also bevor ich denn so richtig „Haue“ bekomme & grün und blau geschlagen werde , hier mal ein paar Infos zum vorhaben:

Übrigens, der Beitrag http://www.xbaseforum.de/viewtopic.php?f=32&t=5367 gehört zum selben Vorhaben.

Ich habe hier etwas vorgefunden, was ich dringend zu verstehen versuche.
Vor mir liegen ca. 1000 Tabellen, etliche davon mit einer Größe im Bereich 1GB, einige sogar deutlich über 2GB. Manche haben einen Index, andere wieder rum nicht. Die Zahl der Datensätze variiert zwischen 0 und mehr als 15 Millionen (ich habe mich nicht verschrieben!). Anhand der Tabellennamen kann ich i.d.R. nicht ableiten was sich dahinter verbirgt. Dokumentation == 0!
Ein paar Tabellen habe ich mir schon genauer angeschaut und bin der Meinung, dass etliche davon gar nicht benutzt werden. Also irgendwelche Überbleibsel von anno dazumal, etc. Meine erste Schätzung ist, dass ca. 1/3 der Tabellen ins „Archiv“ können.

Im Ersten Schritt heißt das Ziel: verstehen, aufräumen, möglichst Dokumentieren & Herr der Dinge werden. Weitere Schritte folgen…

Nun, wie kriege ich es am einfachsten raus, welche Tabellen noch aktuell sind, sprich benutzt werden und welche kann ich bedenkenlos löschen (~archivieren)?
Ich habe überlegt, alle vorhandenen Programme die auf die vorhandene ADS zugreifen einzeln zu starten und zu schauen welche Tabellen dann geöffnet werden. Dieses Vorhaben habe ich dann relativ schnell aufgegeben, da zu viele Programme existieren (etliche kenn ich noch nicht). Dazu werden nicht alle Tabelle direkt beim Programmstart geöffnet, sonder erst wenn sei für bestimmte Aktionen gebraucht werden. Die Alternative, mir den Code der Programme anzuschauen ist genau so mühsam. Das werde ich eh noch machen müssen, um irgendwann zu dokumentieren welche Programme auf welche Tabellen zugreifen, ggf. wie, etc.

Fürs Erste habe ich einen anderen Weg genommen, da ich der Meinung bin so relativ schnell einen ersten genaueren Überblick über das Problem zu bekommen.

1 x die Woche läuft ein selbstgeschriebenes Programm und schaut sich alle vorhandenen Tabellen an. Dabei wird jede vorhandene Tabelle Protokolliert. Z.B. Erstellungszeitpunkt, letzter Zugriff / Änderung, Anzahl Datensätze, Anzahl gelöschter Datensätze, vorhandene Indizes, Größe, etc.
So kann ich relativ schnell erkennen welche Kandidaten ich mir genauer anschauen muss. Also für erste z.B. alle mit 0 Datensätzen. Dann z.B. die, die schon seit einer Ewigkeit nicht mehr verändert wurden (sprich keine Datensatzänderung), etc. So hoffe ich im ersten Schritt die „eindeutigen“ Fälle schon mal zu eliminieren.

Und wozu dann MS Access?
Ganz einfach. Ich möchte relativ einfach alle Infos die Protokolliert wurden auf einmal sehen. Also nicht über eine DBU in Tabellen scrollen, sonder etwas übersichtlicher präsentiert bekommen. Wollte aber hierfür keine Zeit investieren um mir einen Xbase++ Dialog zu bauen. Die Idee, einfach mit Access verknüpfen und ohne Firlefanz ein Formular erstellen. Fertig. Konkurrierenden Zugriff brauche ich nicht fürchten, da ich das ganze dann alleine nutze. Access sollte also nur zum anzeigen dienen.

[Jan]

Mr. Magic,

das ist keine gute Idee! Ich habe berufsmäßig selber lange mit Access "programmieren" müssen. Und glaube mir - das Arbeiten mit dermaßen großen Datenbanken (bzw. unter Access dann Tabellen) ist schon weit hinter dem Stadium des grenzwertig seiens.

Außerdem frage ich mich, ob der Aufwand wirklich geringer ist als alles direkt mit DBU (oder besser noch mit dem Tool von DS-Datasoft) zu erledigen + ein oder zwei kleinen selbstgeschriebenen Tools.

Jan

[brandelh]

Hallo Magic,

so wie du das schreibst, Export der Protokolldatei, kannst du bedenkenlos die Protokoll-DBF mit copy to exportieren.
Für Access musst du aber eventuell einige Felder umsetzen, memo geht dabei automatisch mit der VIA DBFNTX Anweisung,
andere eventuell nicht. Einfache Datentypen sollten keine Probleme bereiten, aber eventuell möchtest du ja Ja/Nein statt .t./.f. sehen.
Es kann auch sein, dass das Datum falsch gelesen wird, dann macht es Sinn das mit dtos() umzusetzen.

[Magic]

das Arbeiten mit dermaßen großen Datenbanken (bzw. unter Access dann Tabellen)

Wir sprechen an einander vorbei. In Access will ich mir nur das Protokoll anschauen. Nicht die Datenbanken selbst!
Dafür habe ich ja mein Advantage Data Access.

[AUGE_OHR]

Ich habe hier etwas vorgefunden, was ich dringend zu verstehen versuche.
Vor mir liegen ca. 1000 Tabellen, etliche davon mit einer Größe im Bereich 1GB, einige sogar deutlich über 2GB.
...
Dokumentation == 0!

das kommt mir bekannt vor ...

Im Ersten Schritt heißt das Ziel: verstehen, aufräumen, möglichst Dokumentieren & Herr der Dinge werden. Weitere Schritte folgen…

und nutzt du dazu keine "Tools" ?

Die Alternative, mir den Code der Programme anzuschauen ist genau so mühsam.

ist es Cl*pper Code ... oder xharbour Code ?

1 x die Woche läuft ein selbstgeschriebenes Programm und schaut sich alle vorhandenen Tabellen an.

das ist eine gute Idee ... aber sagtest du nicht ADS ?

Und wozu dann MS Access?

hm ...also "nur" zur Auswertung und Darstellung ?

das "sammeln" der Daten willst du auch in Access machen oder in Xbase++ ?
ich "sammel" so was in Array das ich dann z.b. an Excel "komplett" übergebe -> 1sec bei 64000 Elementen.

[Magic]

und nutzt du dazu keine "Tools" ?

An was denkst Du denn? Habe da (noch) nichts sinnvolles.

ist es Cl*pper Code ... oder xharbour Code ?

Clipper, Xbase++, VBA und VBScript über ODBC, und

das ist eine gute Idee ... aber sagtest du nicht ADS ?

Korrekt ADS. Sag nicht, dass ADS das von sich aus kann. Ne, ne, ne, das ist nicht möglich.

das "sammeln" der Daten willst du auch in Access machen oder in Xbase++ ?

Selbstgeschriebenes Xbase++ Programm. Es wird in DBF protokoliert.

eventuell möchtest du ja Ja/Nein statt .t./.f. sehen

Das ist kein Problem. Ich nutze es selbst und dann ist es ok wenn da ein .T. oder .F. steht.

[brandelh]

und nutzt du dazu keine "Tools" ?

An was denkst Du denn? Habe da (noch) nichts sinnvolles.

vermutlich meint er "selbstgeschriebene Auswertungsprogramme", Tools ist ein weitgefächerter Begriff, die XbToolsIII würden hier nicht helfen.

Lass dich nicht verwirren, benutze dein Programm um die Protokolldatei nach DBFNTX Format zu exportieren (copy to ... via dbfntx),
dabei kannst du auch die Felder einschränken wenn nötig. Und greife darauf mit Access zu. Das wird gehen, da du ja nur lesend und alleine darauf zugreifen willst.

Eventuell ist es performanter, einen CSV-Export zu schreiben und den in Access einzulesen (aber nicht mit der DELDBE ) ...

Code: Alles auswählen

set alternate to CSV_Export.CSV
set alternate on 
cTxt := ""
for x := 1 to fcount()-1
   cTxt += fieldname(x)+";"
next
cTxt += fieldname(x)+chr(13)+chr(10)
?? cTxt
do while ! eof()
   cTxt := ""
   for x := 1 to fcount()-1
      cTxt += fieldget(x)+";"
   next
   cTxt += fieldget(x)+chr(13)+chr(10)
enddo
set alternate to

PS: Quellcode nicht geprüft, eventuelle Tippfehler beseitigen

[AUGE_OHR]

und nutzt du dazu keine "Tools" ?

An was denkst Du denn? Habe da (noch) nichts sinnvolles.

DFlow, SNAP, DOC, Click ... von Click hat Olaf870 eine Xbase++ Version gechrieben.

ist es Cl*pper Code ... oder xharbour Code ?

Clipper, Xbase++, VBA und VBScript über ODBC, und

wie ? sind das "verschiedene" Applicationen ?

das ist eine gute Idee ... aber sagtest du nicht ADS ?

Korrekt ADS. Sag nicht, dass ADS das von sich aus kann. Ne, ne, ne, das ist nicht möglich.

wenn du mit ADS "Local" arbeitest siehst du natürlich "nichts", aber bei "Server" kannst du doch die Verbindung von jedem User "sehen".

in einem Windows Netzwerk kann man eine "geöffnete freigegebene" Datei übrigens mit "OPENFILES" und der Option /query herausfinden.
http://technet.microsoft.com/en-us/libr ... 90961.aspx

das "sammeln" der Daten willst du auch in Access machen oder in Xbase++ ?

Selbstgeschriebenes Xbase++ Programm. Es wird in DBF protokoliert.

hm ... ein APPEND / REPLACE dauert doch "ewig" ... warum kein ARRAY ... und das "komplett" an Excel übergeben.

[UliTs]

Hallo Magic,

ich habe gerade Dein Thema durchgelesen.
Ist es noch aktuell?
Wenn ja,
Du schreibst, es wird über den ADS auf die Daten zugegriffen. Wird dabei ein Data Dictionary verwendet? Dann wird es richtig einfach! Du kannst über den ARC (Advantage Database Architect) Dir beliebig einfach oder auch komplizierte Views in SQL einrichten. Außerdem kannst Du wunderbar über Trigger den Zugriff auf die Tabellen protokollieren.

Uli