Используя sql server 2012, я подключаюсь к связанному серверу с Pervasive SQL.
Когда я делаю select * или select field1,field2,field3....field15 Я получаю эту ошибку:
Msg 7399, Level 16, State 1, Line 1
The OLE DB provider "MSDASQL" for linked server "KSLAP208" reported an error. The provider reported an unexpected catastrophic failure.
Msg 7330, Level 16, State 2, Line 1
Cannot fetch a row from OLE DB provider "MSDASQL" for linked server "KSLAP208".
Я чувствую, что есть какая-то проблема с памятью? Это не позволит мне выбрать больше определенного количества данных?
тогда как если я выберу небольшой объем данных select field1,field2 работает без проблем.
Что я делаю не так?
Сообщение на веб-сайте Microsoft предполагает, что вы можете обойти эту проблему, отключив предварительную выборку запросов для связанного сервера.
На панели администратора источника данных ODBC на сервере настройте связанный сервер из системного DSN. На вкладке «Производительность» снимите флажок «Разрешить упреждающую выборку данных для запросов». ЛАДНО ЛАДНО. Удалите и заново создайте связанный сервер в SQL Management Studio.
Вы можете отключить предварительную выборку, сняв флажок «Включить предварительную выборку данных для запросов» на вкладке «Производительность» при создании DSN или добавив «PREFETCH = 0» в строку подключения при создании подключения без DSN.
Поскольку у меня нет доступа к области загрузки Pervasive (а соединение ODBC с SQL Server выглядит совершенно иначе в моей установке Server 2012), я не смог это проверить. Это все равно может вам помочь ...
Я знаю, что этот вопрос задавался давно, но люди, которые гуглили и встречали этот пост ...
Я предполагаю, что запрос является золотым, когда вы запускаете его на сервере, с которым связаны?
Каков ваш точный запрос?
Вы делаете:
Select * from "the linked server"
-или-
Select * from openquery("the linked server",'Select * from "the table"')
Есть разница:
Возможен тайм-аут, но я не думаю, что это ваша проблема.
У меня возникла проблема с подключением связанного сервера к mysql. Я пробовал №1 выше и, кажется, помню, что получал ту же бесполезную ошибку. Оказалось, что выполнение №1 работает (или работает лучше всего) только с другими SQL-серверами. При подключении к серверу, отличному от SQL, вы должны использовать # 2 (openquery).
Работает ли это: SELECT TOP 1 field1, field2, field3 .... field15.
Если да, то как насчет SELECT TOP 10 field1, field2, field3 .... field15.
Если да, то как насчет SELECT TOP 100 field1, field2, field3 .... field15.
Повторить и т. Д.
Предполагая, что в какой-то момент он сломается, добавьте предложение ORDER BY для столбца (или набора столбцов), которые являются уникальными. Повторите и отрегулируйте количество рядов, пока не определите виновника. Скажем, например, SELECT TOP 12345 работает, а SELECT TOP 12346 - нет. (Здесь важен хороший ORDER BY, чтобы гарантировать, что он каждый раз возвращает один и тот же набор данных.) Теперь используйте диапазон предложения WHERE, чтобы получить лишь небольшой объем данных, который появляется в нижней части ваших "хороших" данных, а затем немного увеличьте диапазон WHERE, чтобы включить плохую строку. Если сейчас это работает, то это указывает на объем данных, который, по крайней мере, подтверждает ваше первоначальное предположение, и если он все еще не работает, посмотрите на строку, которая будет 12346 в этом запросе, и посмотрите, есть ли с ней что-нибудь странное.
Я могу уточнить, если окажется, что это вас куда-то приведет.