#tsql
#tsql
Вопрос:
у меня есть следующее, которое запрашивает связанный сервер, с которым я должен поговорить.
ВЫБЕРИТЕ * ИЗ
OPENQUERY(DWH_LINK, ‘ВЫБРАТЬ * ИЗ TABLEA ‘)
Обычно он возвращает большую часть данных, но некоторые строки отсутствуют?
Сервер linkeds поступает от клиента oracle
Кто-нибудь сталкивался с этой проблемой в openquery?
Комментарии:
1. есть ли другой способ доступа к данным на связанном сервере, кроме использования openquery
Ответ №1:
У меня была точно такая же проблема.
Основная причина в том, что вы настроили свой связанный сервер с использованием ODBC вместо OLE DB.
Вот как я это исправил:
- Удалите связанный сервер из SQL Server
- Щелкните правой кнопкой мыши по папке «Связанные серверы» и выберите «Новый связанный сервер …»
- Связанный сервер: введите что угодно .. это будет имя вашего нового связанного сервера
- Поставщик: выберите «Поставщик Oracle для OLE DB»
- Название продукта: введите «Oracle» (без двойных кавычек)
- Источник данных: введите псевдоним из ваших TNSNAMES.Файл ORA. В моем случае это было «ABC.WORLD» (без двойных кавычек)
- Строка поставщика: оставьте ее пустой
- Расположение: оставьте его пустым
- Каталог: оставьте его пустым
Теперь перейдите на вкладку «Безопасность» и щелкните последний переключатель с надписью «Быть созданным с использованием этого контекста безопасности:» и введите имя пользователя и пароль для вашего подключения
Так и должно быть!
Комментарии:
1. Потрясающе — это была именно моя проблема. Я не могу поверить, что драйвер ODBC допускал подобные ошибки, но это было так, и теперь это исправлено 🙂
2. Мы также столкнулись с этим, и таково было решение. Чтобы усилить нашу первоначальную путаницу, поведение FETCH FIRST, которое демонстрировал SELECT *, проявлялось, когда в предложении WHERE использовался любой из 3 из 7 столбцов… использование остальных 4 или запуск без WHERE вернуло ожидаемые результаты.
3. Переключение (с поставщика Microsoft OLE DB для драйверов ODBC) на Oracle Provider для OLE DB сработало. Спасибо. Убедитесь, что вы сопоставляете x64 -> (64-разрядные загрузки Oracle Data Access Components (ODAC)) с SQL server. Спасибо.
Ответ №2:
Похоже, это связано с базовыми возможностями поставщика, и другие также столкнулись с этим и подобными ограничениями размера / строки. Одним из возможных решений было бы реализовать итеративный / циклический запрос со встроенной фильтрацией для извлечения определенного количества строк. Я думаю, что в Oracle это может быть связано с использованием rownum (не очень знаком с oracle).
Итак, что-то вроде
--Not tested sql, just winging it syntax-wise
SELECT * FROM OPENQUERY(DWH_LINK, 'SELECT * FROM TABLEA where rownum between 0 AND 500')
SELECT * FROM OPENQUERY(DWH_LINK, 'SELECT * FROM TABLEA where rownum between 500 AND 1000')
SELECT * FROM OPENQUERY(DWH_LINK, 'SELECT * FROM TABLEA where rownum ...')
BOL:
Ссылка
Это зависит от возможностей поставщика OLE DB. Хотя запрос может возвращать несколько наборов результатов, OPENQUERY возвращает только первый.
Ответ №3:
У меня была такая же проблема с использованием Oracle 10 instant client и ODBC. Я использовал этот клиент при подключении к базе данных Oracle 10gR2. Я обратился в службу поддержки Microsoft, и они предложили использовать Oracle 11 instant client. Сюрприз! Удаление 10g instant client, установка 11g instant client и перезагрузка устранили проблему.
Кен
Ответ №4:
У меня была точно такая же проблема с SQL 2014, получающим данные из SQL 2000 через OPENQUERY. Из-за проблемы с совместимостью ODBC мне пришлось сохранить универсальный OLE DB для драйвера ODBC. Более того, проблема была только с учетной записью SQL, не являющейся администратором. Итак, наконец, решение, которое я нашел, состояло в том, чтобы добавить SET ROWCOUNT 0:
SELECT * FROM OPENQUERY(DWH_LINK, 'SET ROWCOUNT 0 SELECT * FROM TABLEA ')
Похоже, что rowcount могло быть где-то изменено с помощью процедуры SQL (или для этого сеанса пользователя), поэтому установка его в 0 принудительно возвращает «все строки».