Führen Sie UPDATE- und DELETE-statementen auf VFP-DBF-fileen auf SQL server aus

Wir migrieren unser Legacy-System-basiertes Visual FoxPro in Java und wir müssen den SQL server konfigurieren, um die DBF-fileen des Systems zu CRUD zu machen, da wir das System in Teilen umschreiben. So werden die Mitarbeiter beide interfacen gleichzeitig nutzen und wir benötigen Echtzeit-Updates in beiden Systemen.

Im Moment bin ich in der Lage, INSERT und SELECT data auf SQL server, aber ich kann nicht UPDATE und DELETE.

Ich habe den folgenden Befehl ausgeführt, um den verknüpften server zu erstellen:

sp_addlinkedserver @server = 'DEN', @srvproduct = 'foxpro', @provider = 'VFPOLEDB.1', @datasrc = 'D:\BaseTeste\denny\denny_db.dbc' 

Und führen Sie die folgenden SQL, um eine Tabelle zu aktualisieren:

 UPDATE DEN...produtos SET familia=1 WHERE id=35 

Und ich habe diesen Fehler erhalten:

OLE DB-Provider "VFPOLEDB" für verknüpften server "DEN" zurückgegebene Meldung "Mehrstufige OLE DB-Operation generierte Fehler. Überprüfen Sie jeden OLE DB-Statuswert, falls vorhanden.

Msg 7333, Stufe 16, Zustand 2, Zeile 1

Kann keine Zeile mit einem Lesezeichen vom OLE DB-Provider "VFPOLEDB" für den verknüpften server "DEN" abrufen.

Wie kann man das lösen? Vielen Dank.

Ich benutze die VFP OleDB regelmäßig und habe kein Problem, irgendwelche Einsätze zu machen, Updates, löscht, wählt …. Eine Sache zu beachten. Ihre Verbindungszeichenfolge kann entweder auf ein Verzeichnis verweisen, in dem sich die Tabellen befinden. Zusätzlich kann die database aufgenommen werden, wenn eine bestimmte .DBC mit den betreffenden Tabellen verknüpft ist.

Wenn Sie eine Abfrage ausführen, insert, aktualisieren oder löschen, müssen Sie die database nicht qualifizieren

DEN …. produtos (was ich vermute, soll Denny_db.Produtos sein – also zeigt database.Table an, um Abfrage zu führen). Tu das nicht … die database ist offen und "sichtbar" aus der Verbindung …. du solltest nur in der Lage sein zu tun ….

 Update Produtos set x = 1 where something = whatever or insert into Produtos (fld1, fld2, fld3) values ( something1, another2, last3) 

Eine andere Sache über VFP, wenn die Tabelle mit einer bestimmten database verknüpft ist, sobald sie geöffnet ist, wenn die entsprechende database nicht geöffnet wird, wird es FORCED offen sein, um alle Trigger und solche zu nutzen. So könnten Sie Ihre Verbindung vereinfachen, um nur auf den path zu zeigen und den Rest der Sachen einfach für Sie zu verletzen.

Eine weitere Anmerkung …. wenn Sie eine Verzeichnisstruktur haben, die Pfade unter ihm mit data an anderen Orten hat, wie zB

 C:\SomeFolder\MainDataPath\ C:\SomeFolder\MainDataPath\SomeArchives\ C:\SomeFolder\MainDataPath\OtherFolder\ 

und machen Sie Ihre Verbindung zu nur der "C:\SomeFolder\MainDataPath\" Standort, Ihre Abfragen können relativen Pfad verwenden, um an data in den anderen Orten wie zu bekommen

 select whatever from SomeRootTable SRT join SomeArchives\SubFolderTable SFT on SRT.KeyID = SFT.LinkKeyID 

Sie haben kein Glück mit einem verknüpften server:

Wenn Sie Visual FoxPro OLE DB Provider als SQL server-verknüpften server verwenden, werden nur Abfragen unterstützt. Der Visual FoxPro OLE DB-Provider unterstützt keine Aktualisierung, Einfügen oder Löschen von Operationen über einen verknüpften server.

http://msdn.microsoft.com/en-us/library/0xzsac67(v=vs.80).aspx

Stattdessen versuchen Sie OPENROWSET mit dem MSDASQL Provider und übergeben Sie den Fox-Pro ODBC-Treiber als das 2. Argument ( Driver={Microsoft Visual FoxPro Driver} )

Mit VFPOLEDB installiert mit SQL server Express 2012 32bit die folgenden scheint zu funktionieren:

 SELECT * FROM OPENROWSET('VFPOLEDB','D:\dir\file.dbf';'';'','file') SELECT * FROM OPENROWSET('VFPOLEDB','D:\dir\file.dbf';'';'','update file set n=2 where n=1') SELECT * FROM OPENROWSET('VFPOLEDB','D:\dir\file.dbf';'';'','delete from file where n=2') SELECT * FROM OPENROWSET('VFPOLEDB','D:\dir\db2.dbc';'';'','tab2') SELECT * FROM OPENROWSET('VFPOLEDB','D:\dir\db2.dbc';'';'','update tab2 set somedate=ctod("12/30/2000") where n=1') 

Die einzige Unannehmlichkeit ist, dass Aktualisierungs- und Löschanweisungen mit Fehler 7357 ergeben, der Ihnen mitteilt, dass keine Zeilen zurückgegeben werden sollen. Sie können es in try / catch Block einpacken und ignorieren 7357 als eine erwartete Bedingung, da tatsächliche statementen sowieso ausgeführt wurden. Um dynamische Parameter zu verwenden, ist es möglich, diese durch exec(@sqltext) auszuführen.