Alesha пишет:

> При выполнении с помощью утилиты isql закачки данных в таблицу в
> текстовых полях (char, varchar) у меня пропадают символы с кодом 13,
> если они есть в значении поля.
>
> Пример скрипта:
>
> create table #test (Value char(*250*))
>
> insert into #test (Value)
> values ('aaaaa
> bbbbb
> ccccc')
>
> select ascii(substring(Value,*6*,*1*)),ascii(substring(Value,*7*,*1*)) from #test

Возможно ISQL переводит всё в запросе в UNIX-style line ending.

На самом деле посылать в языковом запросе непечатные символы на
сервер - дело неблагодарное очень.

Лучше бы вы писали это в виде бинарной константы или
с явно заданными символами перевода.

'aaaaa' + char(10) + char(13) + 'bbbbb' ...

А еще лучше биндить параметр в ODBC или Open Client.
Posted via ActualForum NNTP Server 1.4

Alesha пишет:

> Как это будет выглядеть в виде бинарной константы, можно пример?

0x и затем шестнадцатиричные коды символов, по две цифры на символ.

'aaa' - 0x414141
Posted via ActualForum NNTP Server 1.4

Alesha пишет:

> Смирился, а что остаётся. Использую подмену +char(13)+char(10)+. Но это
> конечно не то решение, что нужно. Да и напрягает тот факт, что просто
> выбрасывается символ из значения поля и всё.

Я хочу подчеркнуть, что это - единственно правильное решение.
И к тому же полагаться, что перевод строки - это именно char(13)+char(10)
(или еще какое-то сочетание этих магических символов) просто нельзя.
Оно на разных платформах разное. Так что ASE-то делает все очень правильно.
Posted via ActualForum NNTP Server 1.4

Alesha пишет:
> Исключение неких символов из заковыченого строкового значения без всяких
> предупреждений - это правильно?

Они непечатные !! Перевод строки на разных системах выглядит по-разному.

> На разных платформах разное, но здесь похоже был принят стандарт в
> пользу одной из платформ.

Да, в пользу UNIX. И языка C. Там перевод строки - '\n'.
Posted via ActualForum NNTP Server 1.4