Почему openquery возвращает 0 строк на сервере SQL, но имеет 900 тысяч строк на целевом сервере?

Нужна помощь, чтобы понять, почему удаленный запрос, который я выполняю на сервере, возвращает 0 строк, но тот же запрос возвращает более 900 тыс. строк в целевой БД.

длина строки меньше 8000 символов, поэтому я не буду ее здесь публиковать. но это структура в основном:

declare @SQL varchar(MAX);
declare @D varchar(15);
declare @Per varchar(15);
declare @NextPer varchar(15);
declare @NextYPer varchar(15);
set @D = N'01-JUN-2019'
set @Per = N'2020004';
set @NextYPer = N'2021004'
set @NextPer = N'2020005'
set @SQL = N' SELECT  ...... '
set @SQL = N'select * from openquery ([LK1], "'+@SQL+'")';
execute( @SQL);
print @SQL;

Примечание: связанный сервер работает и успешно используется в других открытых запросах с более короткими строками. Я попытался использовать EXECUTE (@SQL) AT, но по-прежнему получаю 0 строк. Когда я выполняю вывод на печать непосредственно в БД Oracle, запрос выполняется около 15 минут и дает результаты.

Я предполагаю, что это на SQL Server? Пожалуйста, пометьте его соответствующим образом

— 27.05.2019 14:35

Я бы не ожидал увидеть двойные кавычки " в вашем заявлении OPENQUERY - конечно, это даже не сработает. Чтобы добиться какого-либо прогресса, вам нужно свести проблему к минимальному примеру, который демонстрирует ошибку. В процессе вы, вероятно, сами найдете ошибку

— 27.05.2019 14:37

Пользователь, которого вы используете для доступа к связанному серверу, не обязательно должен совпадать с пользователем, которого вы используете для прямого выполнения запросов, и это может легко привести к несоответствиям. Проверьте учетные данные / сопоставления, настроенные для сервера LK1 (в процессе вы также должны иметь возможность дважды проверить, что у вас есть правильный сервер). Кроме того, попробуйте упростить запрос, пока он не даст какой-то результат, а затем вернитесь к полной форме, чтобы увидеть, что изменилось.

— 27.05.2019 14:45

Спасибо обоим. Я, может быть, приближаюсь. когда я запускаю подзапрос исходного запроса таким же образом, он также возвращает 0 строк. Однако я попробовал это после комментирования параметра @D в предложении where, и он внезапно вернул строки. Я еще поэкспериментирую с параметрами и посмотрю, что даст.

— 27.05.2019 15:26

Подозреваю, что 01-JUN-2019 — единственное значение, которое не может иметь смысла, если его правильно не процитировать (в отличие от чего-то вроде 2021004, которое работает как целочисленная константа). Согласно ответу TT, проверьте, есть ли у вас возможная проблема с цитированием или неявное преобразование в тип даты/времени, которое не сохранилось по ссылке. (Для самого SQL Server единственная безопасная, независимая от локали форма этой константы — это 20190601, если она должна быть неявно преобразована, но у Oracle есть более гибкие функции синтаксического анализа.)

— 27.05.2019 15:32

sql sql-server linked-server openquery

27.05.2019 14:31

ReactJs | Supabase | Добавление данных в базу данных

Это и есть ваш редактор таблиц в supabase.👇

Понимание Python и переход к SQL

Перед нами лабораторная работа по BloodOath:

469

Перейти к ответу Данный вопрос помечен как решенный

Ответы 2

Во-первых, OPENQUERY требует, чтобы вторым параметром была строка запроса. Строка в SQL Server записывается в одинарных кавычках. Из ОТКРЫТЫЙ ЗАПРОС документация:

OPENQUERY ( linked_server ,'query' )

Мало того, SQL, который появляется в этой строке, должен иметь любые одинарные кавычки, которые появляются в запросе, чтобы удвоиться. Предположим, у вас есть SQL, и вы хотите выполнить следующий запрос:

SELECT * FROM some_table WHERE name='TT.';

Вы бы написали это как:

OPENQUERY(lks,'SELECT * FROM some_table WHERE name=''TT.''')

Но если у вас есть это в динамическом операторе SQL, это станет

DECLARE @s VARCHAR(MAX);
SET @s='SELECT * FROM OPENQUERY(lks,''SELECT * FROM some_table WHERE name=''''TT.'''''')';

Так что это взрыв одинарных кавычек даже для самых тривиальных SQL-запросов. Считайте кавычки, убедитесь, что сам запрос соответствует требованиям (т.е. кавычки были правильно удвоены).

Да, я согласен с хлопотами, которые возникают из-за слишком большого количества одинарных кавычек. Я играл со всем, пытаясь найти решение. Спасибо за ответ.

— 27.05.2019 16:13

27.05.2019 15:29

Ответ принят как подходящий

Спасибо всем за участие.

Основной причиной является просто формат параметра Date, который неправильно работал на связанном сервере. Все, что мне нужно было сделать, это изменить мой запрос, чтобы использовать это:

SO_BOOK_DATE < to_date(''@D'' , ''ДД-МОН-ГГГГ'')

вместо

SO_BOOK_DATE < ''@D'' .

27.05.2019 16:11