forum.clarionlife.net

В догонку к динамической строке http://forum.clarionlife.net/phpbb/view ... f=1&t=3421

Вопрос: а есть ли ограничение / лимит на длину строки для prop:sql ???

Хмм, я в CW5 блобы в шестнадцатеричном виде загонял.
Опять же с помощью класса CSTR, правда, пару методов ещё написал - FromHex и ToHex

Loc:Img Cstr
Loc:Path Cstring(260)
...
! Считываем файл из Loc:Path
If Loc:Img.LoadFromFile(Loc:Path)
Message(..)
Return(-1)
End
! Преобразуем в Hex
Loc:Img.Tohex('0x')
! Запишем в файл

! Процедура LoadQueueFromSQL - удобная обёртка для Prop:SQL, процедура Quote берёт строку в апострофы, удваивая оные внутри строки

LoadQueueFromSQL('Insert Dis_File(FileName,Description,Content) Values(' & Quote(Loc:Path2) |
& ',' & Quote(PicName) & ',' |
& Loc:Img.S & ')' )

Там строки под мегабайт были....

https://mega.nz/#!VsIESYZJ!YhyH7YRb1rZq ... 4hORKybBuk

О, Юрий, спасибо за информацию!

Здесь скорее можно нарваться на ограничение с другой стороны.
Если не ошибаюсь, то в MS SQL 2003 была проблема с тем, что он не обрабатывал запросы {Prop:SQL} длиннее 16 KByte
и приходилось дробить передаваемые данные (картинки и документы) на пакеты и потом их собирать на стороне SQL сервера.

Давным-давно у меня запросы для SQLAnywhere занимали почти по 2 Embed'а. Если у Embed'а было ограничение, если не ошибаюсь, 64K, то вот смотрите. Но и то, что можно написать (какой запрос) в таких объёмах? Если только данные передавать? У меня не было прецедента такого.

Я загонял образы отсканированных документов в формате TIFF. И всё загонялось (возможно, и до сих пор загоняется)

Другое дело, что драйвер MS SQL до Clarion 6 не работал с блобами в Record больше 32К, это да.

Но ЗАПИСАТЬ файл данных в Binary-поле в MS SQL, не используя кларионовский File тем не менее можно, используя Prop:SQL . Сам файл преобразуется в шестнадцатеричную форму, которая и используется для формирования команды Insert, пример чего я и привёл.

Вот прочитать такое поле из CW5 несколько более проблематично, приходится нарезать файл на отдельные блоки и считывать поблочно (можно, однако, по нескольку блоков одной командой). Причём в силу понятных причин, кусочки нельзя принимать через String, они режутся по нулевому байту. Поэтому приходится после нарезки преобразовывать в hex, а программой декодировать (знамо дело, класс CSTR и тут незаменим)

Вопрос, в принципе, интересный. Можно же тупо написать: , где LOC:Blob может быть гигайты, и десятки гигабайт, и сотни. На каждом серваке такую конструкцию надо проверять, может prop:SQL и потянет, а проблема будет в драйвере ил в самом серваке.
По-видимому, судя по хелпу, prop{SQL} - string, и ограничение связано с этим, т.е. 4Mb.

kreator писал(а): Table{prop:SQL} = 'update Table set Table.BlobField=' & LOC:Blob

Вот именно такой конструкцией, я в свое время пытался затолкать IMAGE в SQLITE. Ничего не получилось. Так и не понял почему.

1. Ну, кавычек нет - это понятно Table.BlobField=''' & LOC:Blob & '''
2. Мало ли какая хрень в картинке есть, всякие нулевые байты, апострофы, непечатные символы, переходы на новую строку, ещё что... Поэтому блоб должен быть в шестнадцатеричном виде Table.BlobField = 0xff000102.... По крайней мере в MS SQL так. Вроде бы...

kreator писал(а): 'update Table set Table.BlobField=' & LOC:Blob

Кстати! Table.BlobField & Loc:Blob[0 : Loc:Blob{Prop:Size} - 1]