Sql server x64 und x86 Linked server

Ich habe eine Visual FoxPro-Tabelle, die ich von Sql server zugreifen muss. In Sql server x86 würde ich nur einen verknüpften server erstellen. Leider gibt es keinen x64 Treiber für VFP – also kann Sql server x64 keinen verknüpften server erstellen.

Bisher habe ich mich mit folgenden Optionen vertraut gemacht – von denen ich mich besonders lieb habe:

  1. Richten Sie einen x86 Sql server ein, der als Relais verwendet werden soll, damit Abfragen von x64 -> x86 -> VFP ablaufen.

Ich kümmere mich nicht wirklich darum, da ich auch schon da bin, ich bin auch sysadmin. Also das bedeutet, dass ich noch einen Sql server patch, pflegen und überwachen muss – und vielleicht noch einen anderen server (vorausgesetzt, ich verwende nicht nur eine separate Instanz).

Auch da der VFP-Provider nicht mit 4-teiliger Syntax arbeitet, muss ich OPENQUERY verwenden. Denken an all das einzige Zitat, das entkommt, das passieren muss, um eine OPENQUERY-statement zu haben, die in eine andere OPENQUERY-statement eingebettet ist, macht meinen Kopf …

  1. Erstellen Sie eine CLR Table Valued Function, obwohl die Assembly (vermutlich?) Auch x64 sein würde – also müsste ich aus proc (IPC? Webservice?) Gehen, um Abfragen tatsächlich auszuführen

Stellt sich heraus, dass TVFs ein Schema benötigen, also ist diese Option nicht so sauber wie ich anfangs gedacht habe. Ich habe einen Spike, um einen WCF-Client in MSSQL zu bekommen, der eine einzelne Spalte von XML zurückgibt, die dann mit den Sql XML-datatyp-functionen analysiert werden kann. Es funktioniert, und ist eigentlich ein bisschen schöner zu fragen als OPENQUERY da es tatsächlich variables als Parameter nimmt. Das spart mir die meisten der einzigen Zitat und EXEC Tanz.

Natürlich ist WCF in Sql ganz ununterstützt und riecht wie ein hübscher Hack. Ich habe ziemlich ernsthafte Vorbehalte zu performance und Zuverlässigkeit.

  1. Stoppen Sie Abfragen von Sql server zu VFP, und schreiben Sie ein gutes Stück Client-Code

Offensichtlich ist das die richtige Antwort. Aber es gibt eine Menge von Client-Code, der auf Joins zwischen Sql server-Tabellen und VFP-Tabellen stützt. Umschreiben dieses Zeug, um eine Temp-Tabelle zu bevölkern oder Client-Side-Joins scheint wie eine ziemlich große Belastung.

Hier gehofft, dass jemand eine bessere Alternative oder ähnliche Erfahrungen vorschlagen kann.

    Es ist ein böses Problem, ich bin einverstanden.

    SSIS laufen im 32-Bit-Modus, um die data regelmäßig zu importieren (vielleicht auf Anfrage, in einem Job, der von demselben SP ausgetriggers wird) an eine SQL server native Tabelle ist eine andere Option, wenn Sie die Verzögerung aushalten können. Es hängt von der Häufigkeit der dataänderung und Probleme mit der Chance von leicht veralteten data ab.

    Ich glaube, ich habe eine Alternative gefunden. Microsoft hat einen aktualisierten Treiber für Access veröffentlicht , der sowohl in 32-Bit- als auch in 64-Bit-Aromen kommt. Wie der ursprüngliche Jet OleDB-Treiber können Sie auch auf dBase-fileformate von SQL server x64 zugreifen .

    Die einzige Einschränkung ist, dass der DBF in einem der von ISAM unterstützten dBASE- Formate sein muss. Ich habe ein paar Tests mit einem dBASE IV-Format gemacht und es scheint zu funktionieren, mit der folgenden Verbindungszeichenfolge.

    Provider=Microsoft.ACE.OLEDB.12.0;Data Source=c:\folder;Extended Properties=dBASE IV;User ID=Admin;Password=;