Господа,

Помогите пожалуста советом.
В MSSQL создана таблица. Последнее по счету поля F типа text.
По всем правилам игры с ADO с AppendChunk порциями по 4000 (пробовал менять не помогает) добавляю запись в таблицу, поле F заполняю
ZIP-архивом. После считывания этого поля в другом месте и создания по его
содержимому .ActuaSize через раз уменьшается на 2-байта по сравнению с моментом записи. Анализ HEX-кода показал - теряютя 5С 0A = "\◙".
Чуствую надо применять Image type поля F. Подскажите как с ним работать в
в связке VFP6 ADO.

Простите, может так понятнее

Господа,


Помогите пожалуйста советом.
В MSSQL создана таблица. Последнее по счету поле F типа text.
По всем правилам игры с ADO с AppendChunk порциями по 4000 (пробовал менять не помогает) добавляю запись в таблицу, поле F заполняю ZIP-архивом. После считывания этого поля в другом месте F.ActuaSize через раз уменьшается на 2 (ясно, что и созданный по его содержанию файла тоже). Сранение исходного Zip и считанного после сохранения в F показал, что теряютя 5С 0A = "\◙".
Чуствую надо применять Image type поля F. Подскажите как с ним работать в
в связке VFP6 ADO.

Спасибо всем откликнувшимся

У меня получилось так :

При записи в Image field c AppendChunk я использовал функцию CREATEBINARY на сохраняемый кусок обычной строки VFP. Ошибка о несоответствии типа исчезла.

Однако при подъеме с GetChunk в VFP из Image field оказалось возвращется
целочисленный массив размером равной порции считывания.
цикл

#define CHUNK_SIZE 4000
nImgSize = xxx.ActualSize()
nOffset = 0
do while nOffset < nImgSize
nOffset = nOffset + CHUNK_SIZE
aRetArray = xxx.GetChunk(CHUNK_SIZE)
сReadPart = ''
for i=1 to ALEN(aRetArray)
сReadPart = сReadPart + CHR(aRetArray )
endfor
fwrite(fp, сReadPart)
enddo
=fclose(fp)
Ура получился Zip файл

дает правильный результат, но кажется мне ресурсозатратным.

Может здесь прилепить ADO.SRTEAM объект и избежать убого цикла ?