1.0Чудо{вищные} заметкиhttps://miracle.rpz.nameMiRacLehttps://miracle.rpz.name/author/miracle/<p>Второй раз сталкиваюсь с неспортивным поведением со стороны MSSQL. И дабы встретив третий не тратить на него полдня документирую.</p> <em>Имеется:</em><br /> <ol> <li>два <strong>слинкованных MSSQL-сервера</strong></li> <li>подключение к одному из них</li> <li>хранимая процедура на другом</li> </ol> <em>Требуется:</em><br /> <ul> <li>вызвать эту процедуру c набором параметров и получить результат.</li> </ul> <em>Решение:</em><br /> <blockquote>exec LINKED_SERVER.SELECTED_DATABASE.dbo.procedure_<span>name @param_2=value, @param_1=value, @param_3=value…</span></blockquote> <p><strike>Ничего не предвещает беды. Небо чистое, коннект уверенный, лаг умеренный… и тут... растёт напряжение, давит тишина, в жилах стынет кровь и появляется леденящий душу ПИЗДЕЦ!</strike></p> <p>Я не случайно параметры написал "вразнобой". Казалось бы ничего криминального - они же именованы. И всё отлично покуда все параметры принимают какие-либо значения. Но как только окажется что <em>@param_2=null</em> (или @param_1) вы будете приятно удивлены загадочными сообщениями вроде "а почему это параметр_2 не передан?" или "зачем параметр_1 ты передал мне два раза?". И будете долго биться в истерике, когда окажется, что выполняя запрос сразу на нужном сервере, вы получаете нормальный результат без каких-либо сообщений об ошибках. Мистика?</p> <p>Как удалось выяснить - параметр, который null на линкованный сервер попадает уже без имени (т.е. не <em>"@param_2=null, @param_1=value, @param_2=value"</em>, a <strong>"NULL, @param_1=value, @param_3=value"</strong> и как следствие - этот самый NULL в данном случае будет считаться первым входным параметром в процедуре…</p> <p>Решение было тривиальным(и глупым) - вынести все параметры, которые могут быть <strong>null</strong>, в конец объявления. Но если кто-то объяснит суть описываемого явления, и красивый выход из такого положения - буду очень признателен.</p>rich