Sql Server x64 и x86 связанный сервер - PullRequest
Новая
       11

Sql Server x64 и x86 связанный сервер

2 голосов
/ 27 января 2009

У меня есть таблица Visual FoxPro, к которой мне нужно получить доступ с Sql Server. В Sql Server x86 я бы просто создал связанный сервер. К сожалению, для VFP нет драйвера x64 - поэтому Sql Server x64 не может создать связанный с ним сервер.

До сих пор я придумал следующие варианты - ни один из которых мне особенно не нравится:

  1. Настройте сервер x86 Sql для использования в качестве ретранслятора, чтобы запросы отправлялись из x64 -> x86 -> VFP.

Меня это не особо волнует, поскольку помимо того, что я dev, я также являюсь системным администратором. Таким образом, это означает, что мне нужно исправлять, поддерживать и отслеживать еще один сервер Sql - и, возможно, еще один сервер (при условии, что я не просто использую отдельный экземпляр).

Кроме того, поскольку поставщик VFP не работает с синтаксисом из 4 частей, я должен использовать OPENQUERY. Думая обо всех экранирующих одинарных кавычках, которые должны были произойти, чтобы оператор OPENQUERY был встроен в другой оператор OPENQUERY, у меня кружится голова ...

  1. Создайте табличную функцию с CLR, хотя сборка будет (предположительно?) Также x64 - так что мне придется выйти из proc (IPC? Webservice?) Для фактического выполнения запросов

Оказывается, что для TVF требуется схема, поэтому этот параметр не так чист, как я изначально думал. Я сделал пайк, чтобы включить WCF-клиента в MSSQL, который возвращает один столбец XML, который затем можно проанализировать с помощью функций типа данных Sql XML. Это работает, и на самом деле запрос немного лучше, чем OPENQUERY, поскольку он фактически принимает переменные в качестве параметров. Это экономит мне большую часть одиночной цитаты и танца EXEC.

Конечно, WCF внутри Sql полностью не поддерживается и пахнет как довольно большой взлом. У меня довольно серьезные сомнения по поводу производительности и надежности.

  1. Прекратите делать запросы с Sql Server на VFP и перепишите хороший кусок клиентского кода

Очевидно, это «правильный» ответ. Но существует много клиентского кода, основанного на соединениях между таблицами Sql Server и таблицами VFP. Переписать этот материал, чтобы заполнить временную таблицу или выполнить соединения на стороне клиента, кажется довольно большим бременем.

Здесь мы надеемся, что кто-то может предложить лучшую альтернативу или что-то подобное.

Ответы [ 2 ]

2 голосов
/ 27 января 2009

Это неприятная проблема, я согласен.

Службы SSIS, работающие в 32-разрядном режиме для регулярного импорта данных (возможно, по требованию, в задании, запускаемом одним и тем же SP) в собственную таблицу SQL Server, - еще один вариант, если вы можете выдержать задержку. Это будет зависеть от частоты изменения данных и проблем с вероятностью немного устаревших данных.

0 голосов
/ 29 октября 2010

Я думаю, что нашел альтернативу. Microsoft выпустила обновленный драйвер для Access , который выпускается как в 32-битном, так и в 64-битном вариантах. Как и оригинальный драйвер Jet OleDB, это позволит вам получать доступ к форматам файлов dBase из SQL Server x64.

Единственное ограничение - DBF должен быть в одном из форматов dBASE , поддерживаемых ISAM . Я провел несколько тестов, используя формат dBASE IV, и он, кажется, работает, используя следующую строку подключения. 

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