Чудо{вищные} заметки

Второй раз сталкиваюсь с неспортивным поведением со стороны MSSQL. И дабы встретив третий не тратить на него полдня документирую.

Имеется:

1. два слинкованных MSSQL-сервера
2. подключение к одному из них
3. хранимая процедура на другом

Требуется:

• вызвать эту процедуру c набором параметров и получить результат.

Решение:

exec LINKED_SERVER.SELECTED_DATABASE.dbo.procedure_name @param_2=value, @param_1=value, @param_3=value…

Ничего не предвещает беды. Небо чистое, коннект уверенный, лаг умеренный… и тут… растёт напряжение, давит тишина, в жилах стынет кровь и появляется леденящий душу ПИЗДЕЦ!

Я не случайно параметры написал “вразнобой”. Казалось бы ничего криминального – они же именованы. И всё отлично покуда все параметры принимают какие-либо значения. Но как только окажется что @param_2=null (или @param_1) вы будете приятно удивлены загадочными сообщениями вроде “а почему это параметр_2 не передан?” или “зачем параметр_1 ты передал мне два раза?”. И будете долго биться в истерике, когда окажется, что выполняя запрос сразу на нужном сервере, вы получаете нормальный результат без каких-либо сообщений об ошибках. Мистика?

Как удалось выяснить – параметр, который null на линкованный сервер попадает уже без имени (т.е. не “@param_2=null, @param_1=value, @param_2=value”, a “NULL, @param_1=value, @param_3=value” и как следствие – этот самый NULL в данном случае будет считаться первым входным параметром в процедуре…

Решение было тривиальным(и глупым) – вынести все параметры, которые могут быть null, в конец объявления. Но если кто-то объяснит суть описываемого явления, и красивый выход из такого положения – буду очень признателен.

Коллега(привет Денис) столкнулся с багом в php-mssql, который может съесть ваш мозг.

Предупреждаю – пустые строки вовсе не пустые! Говорят это ошибка в либе, хотя и воспроизводиться и в win и в *nix (т.е. либы разные). Написал разработчику – а вдруг поможет.

А пока имейте ввиду – если в resultset могут быть пустые строки – надо их сделать таковыми самостоятельно (примерно так: $row["field"] = ($row["field"] != " ") ? $row["field"] : "";) – разумеется, если у вас за каким-то лесом в базе храняться одиночные пробелы, вам очень не повезло ;o)

В тайге вымерли все медведи. А виноваты в этом эти ребятки.

Extension пока недокументирован. Список функций мало чем отличается от имеющегося.

Зачем понадобилось писать свой драйвер? Почему нельзя было приложить вектор усилий к доработке существующего ?

А в существующем есть две беды, которые мне мешают:

1. Ограничение на длину varchar – 255. Это “лечиться” только конвертированием в text.
2. “Неработа” в persistent-mode, которая заключается в том, что сервер (веб в первую очередь, sql потом) зависает после некоторого времени работы с mssql_pconnect (Богдан привет ;o) ).

Корни второй проблемы я кажется нашёл – bug#42584, но толи проблема беcпокоит только меня, толи не столь сильно беспокоит других. Маленькая просьба к почитателям этого поста – проголосуйте за важность этого бага (если он вам не безразличен разумеется).