(mssql 2000 +pb9)
Задача: получение строки с сообщением из хранимой процедуры. Делаю так: объявляю аргумент output типа varchar(1000)
и на клиенте его считываю:
Проблема: ODBC обрубает возвращаемую строку до (прибл.) 255 символов (точно не измерял). Как получить строку без обрубания?
Наивно попробовал объявить аргумент типом text , но этому типу в mssql 2000 присваивать низя. Что предложите? Сообщение об ошибке передавать через временную таблицу?
Спасибо.

Факт, что ODBC (и соответственно native драйвер PB) не переваривает char и varchar более (примерно) 255 символов, но столбцы таблиц с типом text нормально отбирает. А вот как быть с текстовым параметром процедуры?
Да и вообще, всё что ли на интерфейсе OLE DB в PB работают? Как длинные строки из БД получаете?

То есть, как длинные строки из хранимой процедуры получаете?

oleg_shishkinпри вызове процедуры передавайте ей переменную уже проиницилизированную строкой в 1000 символов

string s_err = space(1000)
oleg_shishkin, Вы когда-нибудь хранимую вызывали с output-параметрами на power script? Это Вам не winapi, которым действительно достаточно проинициализировать переменную.. Здесь проблема ODBC.

Я спрашивал не о методе преодоления ограничения на varchar в аргументе процедуры, а о других работающих подходах к тому, чтобы получить сообщение об ошибке из хранимой процедуры!

Разъясняю ещё раз задачу: обработка данных производится в хранимой процедуре, на клиентскую часть необходимо передать длинное сообщение, например "Ошибка обработки такого-то объекта с параметрами: ...". Передача сообщения через output-аргумент процедуры приводит к отсечению части текста из-за особенности PB-native драйвера. Какие другие подходы предложите?

Один из вариантов -- использовать специальную таблицу, в которой в поле типа text хранить сообщение. Но как-то сложно для такой не очень долгой обработки. Если бы процедура отрабатывала длительное время -- то можно использовать таблицу-журнал, в которой хранить этап обработки и возможное сообщение пользователю. Но мой случай работает быстро, секунды, только сообщение пользователю большое.

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

Ещё один подход придумал -- использовать несколько output-переменных для сообщения и склеивать их на клиенте.

Но все эти подходы мне не нравятся, поделитесь, кто как возвращает сообщения из хранимой процедуры? Может это вообще "плохой тон", а возвращать надо только код ошибки и на клиенте его расшифровывать, типа 0 = "Всё хорошо", 1 = "Всё плохо", 2 = "Могло быть и хуже".. :-)

AIS savosin_sergeyКак длинные строки из БД получаете?
Они в БД как blob. Получаю отлично. А потом перевожу в string. Так и живем. :)
Из таблицы или из хранимой процедуры? Пример с получением длиннющей строки из хранимой процедурой можно?

text - я считал его аналогом bloba, размер поля text - до 2Гигабайт

oleg_shishkin
У нас все так происходит :)
В вызываемую процедуру передается не переменная, а указатель, где хранится символьный массив
. Соответсвенно если под него не будет выделено место, то возвращаемые данные будут просто усечены. Все массивы и строковые переменные передаются по ссылке (указателем - ref). Поэтому никто под них кроме Вас выделять место не будет.

Пожалуйста, приведите пример. Не понимаю, о каких указателях на строку в хранимых процедурах идёт речь

oleg_shishkin
Указанный метод вызывает ошибку в PB9 при работе с ODBC
правильней работать
объявляете у объекта транзакция в Local External Functions свою процедуру

FUNCTION long mo_do_entrance( int doc_id,ref string s_err) RPCFUNC ALIAS FOR "dbo.mo_do_entrance"

и вызываете соответственно

string s_err=space(1000)
long doc_id,ret_value

......
ret_value = sqlca.mo_do_entrance(doc_id,s_err)

и далее по тексту
oleg_shishkin, спасибо за ответ! Кстати, у меня в хранимой процедуре аргумент doc_id типа int, этому TSQL-типу в power script соответствует тип long.

Сделал, как Вы предложили - с использованием Local External Function, предварительно добавив наследника transaction в приложение. Объявил функцию:
Вызываю её:
Если строковую переменную не инициализировать, то ничего не получаю в ней после вызова, если инициализирую - то насколько я её пробелами заполнил, настолько результата в ней и получаю. Но! Если инициализировать более чем 255-ю пробелами, но после вызова функции, получаю ошибку:

Я же говорил, ODBC не обманешь - у неё varchar всегда не более 255 символов! другое дело - text или blob.

А Вы уверены, что Ваш пример работает на native драйвере, а не на OLE DB?

ФилиппА что значит "Если инициализировать более чем 255-ю пробелами, но после вызова функции" ?
опечатка. Если инициализировать 256 - 1000 пробелами, ТО после вызова функции в SQLCA будет указанная ошибка

oleg_shishkinВы определитесь - если вы используете драйвер MSS - то да он поддерживате только 255 символьные строки, драйвер ODBC (желатетельно Microsoft Native Client) - любые.
Используем драйвер MSS. Я не подумал, что кроме OLE DB и MSS драйверов есть ещё и ODBC!
Столбцы типа text драйвер MSS переваривает, даже входные параметры процедуры типа text передаются нормально, а может и выходные нормально принимаются (не пробовал), но что от этого толку: я не знаю, как в хранимой процедуре переменной типа text присвоить сообщение об ошибке!

oleg_shishkin
Драйвер MSS больше не поддерживается. Переходите на Microsoft Native Client
он содержит в себе ODBC и OLEDB драйвера и поддерживает все новые версии SQL сервера. И в нем нет проблем с длинными символьными строками. Если нужна строка соединения - выложу.
Да, покажите пожалуйста. А в чём его принципиальное отличие от OLE DB-драйвера, который поставляется с power builder? В чёи преимущество?