SQL-запрос дает неверный результат на связанном сервере

Question

Я пытаюсь получить пользовательские данные из 2 таблиц, одной локально и одной на связанном сервере, но при запросе к удаленному серверу получаю неправильные результаты.

Я сократил свой запрос до

select * from SQL2.USER.dbo.people where persId = 475785

для тестирования и обнаружил, что когда я запускаю его, я не получаю никаких результатов, хотя я знаю, что человек существует. (persId - это целое число, db - это SQL Server 2000, а dbo.people - это, кстати, таблица)

Если я копирую / вставляю запрос и запускаю его на том же сервере, что и база данных, он работает.

Кажется, что это влияет только на определенные идентификаторы пользователей, например:

select * from SQL2.USER.dbo.people where persId = 475784

отлично работает для пользователя, прежде чем тот, который я хочу.

Странно, я обнаружил, что

select * from SQL2.USER.dbo.people where persId like '475785'

тоже работает, но

select * from SQL2.USER.dbo.people where persId > 475784

возвращает записи с именами persIds, начинающимися с 22519, а не с 475785, как я ожидал.

Надеюсь, что это имеет смысл для кого-то

Есть идеи?

UPDATE: Из-за внутренних опасений по поводу внесения каких-либо изменений в живую таблицу пользователей я временно переместил свою базу данных, чтобы они оба находились на одном сервере, поэтому проблема со связанным сервером не возникает. Как только вся партия будет перенесена в отдельный кластер, я смогу провести надлежащее расследование. Я обновлю обновление, как только это произойдет, и я смогу пройтись по всем предложениям. Спасибо за вашу помощь.

Answer 1

Является ли dbo.people таблицей или представлением? Я видел нечто похожее, когда базовая схема таблицы была изменена, и удаление и воссоздание представления устранило проблему, хотя тот факт, что запрос работает, если выполняется непосредственно на связанном сервере, действительно указывает на что-то на основе индекса ..

Answer 2

Тот факт, что LIKE работает, не является главной подсказкой: LIKE заставляет целые числа в строку (поэтому вы можете сказать, что поле WHERE LIKE '2%', и вы получите все записи, которые начинаются с 2, даже если поле имеет целочисленный тип ). Ваши неверные сравнения заставят меня думать, что ваши индексы повреждены, но вы говорите, что они работают, когда не используются по ссылке ... однако выбранный индекс может отличаться в зависимости от использования? (Кажется, я вспоминаю случай, когда у меня были повторяющиеся индексы, и только один был устаревшим, хотя это было слишком давно, чтобы вспомнить точную причину).

Тем не менее, я бы попытался перестроить ваш индекс с помощью команды DBCC DBREINDEX (tablenname). Если выясняется, что это исправляет ваш запрос, вы можете перестроить их все: вот скрипт для их простой перестройки.

Answer 3

Используется ли для связанного сервера такое же сопоставление? В зависимости от используемого индекса, возможно, что-то подобное может произойти, если серверы будут не совместимыми, но связанный сервер настроен с совместимыми (что говорит Sql Server об этом может выполнить запрос на удаленном сервере).

Answer 4

Для меня это звучит как ошибка - я читал о некоторых проблемах в этом духе, btu не могу вспомнить, что конкретно. Какую версию SQL Server вы используете?

select * from SQL2.USER.dbo.people where persId = 475785

для PersID, который не работает как:

SELECT *
FROM OpenQuery(SQL2, 'SELECT * FROM USER.dbo.people WHERE persId = 475785')

себя

Answer 5

Я бы проверил следующее:

• Проверьте свое определение на связанном сервере и убедитесь, что SQL2 является сервер вы ожидаете, что это будет
• Проверка и сравнение планов выполнения как с удаленных, так и с локальных серверов
• Попробуйте подключиться по IP-адресу, а не по имени, чтобы убедиться, что у вас есть правильный компьютер
• Поместите код в хранимую процедуру на удаленном компьютере и попробуйте вызвать его вместо