[решено] Login failed for user '(null)' при запросе данных с другого сервера

[leospb]

Текущаяя ситуация:
На сервере SRV1 (Win2003 EE 32bit) установлены SQL2000 и SQL2008
всё прекрасно работает
На сервере SRV2 установлен SQL2000
тоже всё работает
Потребовалось получить данные в хранимой процедуре на SRV1 из-под SQL2000 с SRV2
В результате получили:

Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection.

Все учётки на своих местах с правильными правами.

Если запрос сделать из-под SQL2008, то всё Ok.
Мало того - какое-то время (~10 мин) всё работает и из-под SQL2000.

Как вылечить?

[Delirium]

Идентичная ситуация: http://www.sql.ru/forum/actualthread.aspx?tid=157656
И в поиске куча ответов: http://www.google.ru/#hl=ru&source=hp&q=Login+failed+for+user+%27(null)%27.+Reason%3A+Not+associated+with+a+trusted+SQL+Server+connection&aq=f&aqi=g1&aql=&oq=&gs_rfai=&fp=3c0a017de54007bb
Особо внимательно прочтите статью на http://social.msdn.microsoft.com/forums/en-US/sqlsecurity/thread/9960cce7-bf46-45d2-918c-808500a5c246/

Named pipes передает NTUserName
А TCP/IP нет!

here how I resolved it
1-Go to your report's property
2- Go to datasource and check Credentials stored securely in the report server
enter user name password
3- Check Use as Windows credentials when connecting to the data source
4- Apply

[leospb]

Спасибо за ссылки, но там я уже был.
На именованные каналы переключились первым делом (известная штука, хотя и по TCP/IP как правило всё работает).
Разъясню подробнее (может я плохо сформулировал изначально):

Если физически залогониться на SRV1 и запустить SQL Enterprise Manager или SQL Server Management Studio (напоминаю - у меня 2 SQL-сервера рядом стоят - это важно), то запрос к SRV2 проходит на ура. Мало того, после этого с удалённого компа запросы тоже отрабатываются, но ограниченное время и только для того логина, под которым зашли на SRV1.

Если быстренько выйти на SRV1 на логон и дать другому пользователю проделать вышеописанное, то и он со своего компа сможет некоторое время работать (т.е. часть времени работают вдвоём).

Во какие чудеса. Как их победить - ума не приложу.

Чуть не забыл, когда переставляли сервер SRV1 (уже и до этого дошло), то без SQL2008 всё работало.
Установка клиента SQL2008 на клиентских машинах не помогает.

[Delirium]

leospb, ну тогда танец с бубном: какие протоколы использует 2000 и 2008? Может имеет смысл пересадить один SQL на одни протоколы, второй - на другие? Чтобы не было конфликтов при обращении.

[leospb]

Пробовал - не помогает.
Спинным мозгом чую, SQL2008 гадит, где - не могу понять.

[Delirium]

leospb, а если отключить временно службы 2008-го и проверить? Хоть понятно будет, точно в его сторону копать или нет?

[leospb]

А что это даст?
Кроме самого сервера и агента 2008-ой замещает остальное своими приблудами.

[Delirium]

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

[leospb]

Конечно пробую.
Только результат пока нулевой.

[leospb]

Единственное, чего добился - это по именованным каналам:
SQL Server does not exist or Access Denied
При этом, как оказалось, SQL2008 совсем не причём.
Чего этой заразе ещё надо - не пойму.
Прямой-то запрос на каждый сервер и с сервера на сервер проходит нормально, значит и с правами вроде как всё нормально.

(А по TCP/IP login действительно не передаётся.)

Экспериментировать больше не могу (людям работать надо). Как временный вариант закатал все БД на один сервер.
По мере возможности к этому вопросу возвращаться буду, т.к. сбор данных в одном запросе с разных БД на разных серверах процесс регулярный.

[leospb]

Всё - аврал закончился, мозги встали на место и всё решилось само собой.
Как говорится: учите матчасть, того кто не знает - ох и бьют.
Короче:
Allow cross-database ownership chaining=true
И всё !...