DBF gemeinsam mit DOT NET

[Bernd Reinhardt]

Hallo.

Ich muss mit einer VB DOT NET Anwendung auf eine gemeinsame Datenbank zugreifen.
xBase++ 1.9.331 oder 335. Allerdings sollten beide Programm Daten einfügen und ändern können.
Löschen ist nicht notwendig.
Das Problem ist auch das die Datei 6 Indexe hat, die von beiden Programmen mitgeführt werden müssten.
Als Alternative könnte ich die Datei in einen SQL-Server legen. Dann müsste ich aber mein Programm für
den einen Kunden ändern und auch einen SQL Server installieren.
Mir wäre es lieber er könnte irgendwie auf die dbf-Datei zugreifen.
Zur Zeit verwende ich NTX aber da was zu ändern wäre kein Problem.
Gibt er hierzu eine Lösung?
ACCESS erscheint mir auch etwas umständlich in der Anbindung mit xBase++.

Gruß
Bernd

[brandelh]

Hi,

man könnte von Xbase++ über ODBC auf die DBF ohne Index zugreifen (SQLExpress), das müsste - soweit ich weiß - auch dem VB Zugriff entsprechen.
Somit wären beide Zugriffe im Prinzip kompatibel (garantieren kann ich das nicht).

Die NTX Indexdateien hingegen werden nach meiner Kenntnis nicht von dem ODBC Treiber unterstützt.
Wenn dem so ist, würden die Xbase++ NTX Zugriffe durch konkurierende ODBC Zugriffe gestört,
weil der Index nicht angepasst wird, wenn Indexfelder geändert oder neue Sätze hinzugefügt werden.
Ich bezweifle auch, dass das Sperrverhalten kompatibel ist.

[AUGE_OHR]

Ich muss mit einer VB DOT NET Anwendung auf eine gemeinsame Datenbank zugreifen.
xBase++ 1.9.331 oder 335. Allerdings sollten beide Programm Daten einfügen und ändern können.
Löschen ist nicht notwendig.

Frage : existiert die VB App mit der DBF schon ?
wenn nein, bist du dann auch der Autor der VB App ?

Als Alternative könnte ich die Datei in einen SQL-Server legen.
Dann müsste ich aber mein Programm für den einen Kunden ändern und auch einen SQL Server installieren.
Mir wäre es lieber er könnte irgendwie auf die dbf-Datei zugreifen.
Zur Zeit verwende ich NTX aber da was zu ändern wäre kein Problem.
Gibt er hierzu eine Lösung?

wenn jemand mit VB auf DBF zugreifen will dann sprechen wir gewöhnlich von M$ Produkten wie FoxPro Dateien.
mit NTX können die meisten nichts anfangen.

VB selbst hat doch IHMO keine "native" DBF "Treiber" sondern benutzt M$ ADO, Jet.OLEDB oder ODBC für den Zugriff.

wenn man nun von einem "gemeinsamen" SQL Server spricht -> ADS
Vorteil : es gilt für alle möglichen Programmiersprachen "Treiber" für den Client Zugriff
Nachteil : teuer

Das MySQL Project von Hector Pezoa enthält einen Xbase++ "Wrapper" für die "Navigation" ( SKIP, SEEK, GOTO etc.)
sowie dem "Locking" und ein "Browse" existiert auch schon.
Vorteil : "free" ( benötigt ot4xb)
Nachteil : man muss "selbst" mitarbeiten

nicht zu vergessen PostgreSQL via DBEpg ... wenn man das erst mal in Griff bekommt
Vorteil : sollte sich verhalten wie von FOXDBE "gewohnt"
Nachteil : Liefertermin von Xbase++ v2.x ?

ACCESS erscheint mir auch etwas umständlich in der Anbindung mit xBase++.

auch bei Access hat man doch meistens einen SQL Server als Frontend.

[Martin Altmann]

Moin Jimmy,

auch bei Access hat man doch meistens einen SQL Server als Frontend.

Nie nicht - weder bisher, noch in Zukunft
Aber als Backend.

Viele Grüße,
Martin

[AUGE_OHR]

auch bei Access hat man doch meistens einen SQL Server als Frontend.

Nie nicht - weder bisher, noch in Zukunft
Aber als Backend.

ist heute der 1st April ?

[Martin Altmann]

Nein - wie kommst Du darauf?
Du schriebst, man hat einen SQL-Server als Frontend. Das ist Unsinn - ein SQL-Server ist immer das Backend! Das Frontend ist die GUI (in Deinem Beispiel die Access-Anwendung).

Viele Grüße,
Martin