JOIN über unterschiedliche DBsysteme möglich?

[PASST]

Das große Problem scheint zu sein, dass dBase Tabellen sich nicht einbinden lassen.
Oder aber ich weiß nicht wie es geht!

[PASST]

So, ich habe das ganze jetzt mal ein bisken getestet.

Dies ist unter gewissen Bedingungen eine funktionierde Variante:

SQL-Code:

SELECT * FROM OpenDataSource ( 'Microsoft.Jet.OLEDB.4.0', 'Data Source="<Laufwerk:\Pfade\";Extended Properties=dBASE III;')...tabelle1

Wichtig dabei ist, dass Laufwerk ein lokal existierender Laufwerksbuchstabe ist. Es werden keine gemappten Freigaben akzeptiert und auch keine UNC-Pfade. Außerdem müssen die dBase-Tabellen Indexfrei sein.

Beide Bedingungen kann ich nicht erfüllen. Außer ich starte vorher eine Kopieraktion und bearbeite die dBase-Dateien byteweise, so dass das Index-Flag entfernt wird.

Hm, ....

[shmia]

Zitat:

Zitat von PASST

Das große Problem scheint zu sein, dass dBase Tabellen sich nicht einbinden lassen.

Tja, zwischen Microsoft und dBase gibt es eine langjährige Feindschaft. :evil:
Also ich kenne im Prinzip zwei Wege um an dBase Tabellen ranzukommen.

1.) über die Jet-Engine (also der Kern von MS Access) ist auch so ein halblebiger dBase Zugriff möglich.
(der Treiber ignoriert die Indexdateien und liest nur *.dbf-Dateien. Auch Row-locking wird ignoriert.
Tabellen, die mit Unterstrich beginnen werden nicht erkannt)
ADO -> OLE DB -> DAO(=Jet Engine) -> dBase

2.) über den Foxpro ODBC-Treiber
ADO -> OLE DB -> ODBC Provider -> ODBC -> Foxpro ODBC-Treiber
dieser Treiber kann mit Indexdateien von Clipper nicht umgehen.

Hier die Connection-Strings dazu:
http://www.connectionstrings.com/?carrier=dbffoxpro
Bei Extended Properties ist dBASE III, dBase IV und dBase 5.0 zulässig.

Es gibt/gab auch bessere ODBC-Treiber, die aber Geld kosten.

[PASST]

Ich habe im Entwickler-Forum.de ein Beitrag gefunden, der einen etwas anderen Ansatz hat. Allerdings wohl unter Berücksichtigung MS SQL Server 2005 (Express).

[PASST]

:) Hurra, ich habe jetzt eine Variante gefunden, die mit UNC-Pfad funktioniert:

SQL-Code:

SELECT * FROM OPENROWSET(
'MSDASQL','DRIVER={Microsoft Dbase driver (*.dbf)}',
'SELECT * FROM \\SERVER\Pfade\Tabelle1.dbf')

Das einzige Problem ist noch, dass ich vorher das Byte für den MDX-Flag der dBase Dateien löschen muss. Das ist aber nicht wirklich ein Problem, da Clipper zwar diesen Flag setzt, aber selber nicht verwendet. Außerdem will ich wie gesagt die dBase Daten nur lesen und nichts schreiben.

[shmia]

Zitat:

Zitat von PASST

Ich habe im Entwickler-Forum.de ein Beitrag gefunden, der einen etwas anderen Ansatz hat.

Ja, das Kochrezept in Beitrag #4 ist ganz interessant.
Er verwendet Verbindungsserver (=Linked Server) und den Foxpro ODBC-Treiber.
download hier: http://www.microsoft.com/downloads/d...a-95a3289c5fd4
Das müsste analog auch auf den SQL Server 2000 passen.

Hab's grad' mal auf MS SQL Server 2000 SP4 getestet:
Tabellen mit SELECT abfragen geht. Update von Tabellen geht nicht.

[joachimd]

Zitat:

Zitat von shmia

1.) über die Jet-Engine (also der Kern von MS Access) ist auch so ein halblebiger dBase Zugriff möglich.
(der Treiber ignoriert die Indexdateien und liest nur *.dbf-Dateien. Auch Row-locking wird ignoriert.
Tabellen, die mit Unterstrich beginnen werden nicht erkannt)
ADO -> OLE DB -> DAO(=Jet Engine) -> dBase

2.) über den Foxpro ODBC-Treiber
ADO -> OLE DB -> ODBC Provider -> ODBC -> Foxpro ODBC-Treiber
dieser Treiber kann mit Indexdateien von Clipper nicht umgehen.

3. über Advantage (Local Server)

[PASST]

@shmia
Wie kann ich denn unter MS SQL 20000 einen Linked Server einbinden?

[PASST]

Jetzt wo ich die Möglichkeit habe lesend auf meine dbase DB zuzugreifen, würde ich auch gerne die anderen Abfragen auch per ADO ausführen. Allerdings erhalte ich dabei eine Fehlermeldung bzgl. Datums:

SQL-Code:

where datum >= (16/5/2008)
--> Error converting data type DBTYPE_DBDATE to datetime.

Wenn ich das Datum durch year, month und day(datum) ausdrücke, funktioniert es.

Wie kann ich also das Datum-Kriterium umbauen?

[mkinzler]

SQL-Code:

where datum >= '16/5/2008'

oder besser gleich mit (SQL-)Parametern