Здравствуйте уважаемые участники.
Кто-нибудь сталкивался с преобразованием картинки в строку (неограниченной длины) и обратно для 1с версии 7.7 (сетевая или для sql). Интересует именно хранение картинки в базе как строки с преобразованием для отображения на форме. Если у кого-нибудь есть сведения или мысли по этой теме, откликнитесь пожалуйста.
Уважаю вас всех и каждого в отдельности.
Жду ответа. Денис.

desty писал(а) 07. Мая 2007 :: 12:01:
Длинные строки и таблица _1sconst никак не связаны.
Это в dbf длинные строки хранятся в 1sblob.dbf, а в sql хранятся "там где положено" в полях таблиц типа text.

(0)
Имхо, без преобразования двоичных данных в строку, например по алгоритму base64, не обойтись.
Могу предложить только работу через временный файл. Есть простенькая консольная утилита:
http://dev.citykirov.ru/dlcount.php?url=base64.zip
Цитата:

А вот уже прекодированный временный файл закидывать в базу посредством BinaryData.

Что за черт А зачем хранить картинки текстом?
Надо создать в базе свою таблицу с полем image и хранить их там.

Цитата:

Имхо утверждение абсолютно безосновательно.

По скорости: я думаю что скорость будет не меньше, а может и больше. Скорость передачи данных с MSSQL достаточно высока. Данные идут в чистом виде по TCP, я не вижу где там могут быть потери на самом процессе передачи. Используется точно такой же сокет и транспортная библиотека. Работает тот же стек протокола. Механизм получения данных BLOB ни чем не отличается от обычной передачи массива данных через сеть.

По позиционированию: (по некоторому идентификатору надо найти в хранилище блок данных для передачи) не думаю что индексы MSSQL менее эффективны чем индексы файловой системы (по именам файлов). Я опять же склонен считать что они гораздо более эффективны. Хотябы по тому что индексное выражение описывается в БД гораздо строже, кроме того идентификатор можно сделать просто int, да пространство значений индекса ограничивается одной базой/таблицей, а в файловой системе это иерархическое дерево строк(!), да еще и по всему тому.

По оптимальности хранения: как не крути, а картинка это часть данных и должна храниться в базе данных, это ведь удобнее. По физически занимаемому месту в файловой системе можно получить выигрышь за счет более мелкого кластера, в MSSQL страница 8к и ни куда не денешься. Имхо это не существенно на самом деле, кто щас место считает

С практической точки зрения: при работе через файловую систему будет работать служба доступа на sql-ном сервере, а у нее на таких серверах приоритет понижен, ее файловый кэш уменьшен, сервер сконфигурирован как сервер приложений, а не как файловый сервер. Однако при хранении картинок в БД при существующих на данных момент средствах 1cpp нам придется сначала стянуть ее на локальный диск во временный файл, а потом из него уже получить объект Картинка для отображения, а при хранении в файловой системе мы можем получить объект Картинка сразу с сервера. Формировать экземпляры объектов Картинка из данных рекордсета конечно же можно, но это не сделано, это было бы еще эффектинее.

Вообще говоря, надо провести тестирование, оно даст наиболее точные с практической точки зрения результаты.

Храним в текстовом поле сертификаты( работает года 4)
Для этого был написан COM объект (Лежит на проклубе)
База 1с77 УРБД. Все остальные способы по хранению и передачи сертификатов оказались неудобными.

JohnyDeath писал(а) 09. Июня 2007 :: 06:27:

а можешь ссылку показать? [/quote]

http://1c.proclub.ru/modules/mydownloads/personal.php?cid=115&lid=3163
Последняя версия компоненты прикреплена
Описание и как ставить в архиве с проклуба

vip писал(а) 09. Июня 2007 :: 09:39:

К сожелению ВК не занимаюсь.
Почитал про вариант Z1. Там надо запускать экзэшник, который должен постоянно пахать. ИМХО, как-то не очень красиво. И сразу задался вопросом: "а почему не сделали тоже самое, но в виде ВК?". Оказывается сделали. 
не мог бы выложить? 

Цитата:

К сожалению, нет. Пишу только для себя и поэтому внутри ВК полное безобразие. Это только кусочек многочисленных методов, которые никому, кроме меня не нужны. Тем более пишу на VB. Стыдно А решениями поделиться могу.

fez писал(а) 09. Июня 2007 :: 22:27:

Отнюдь
Однако и Z1 прав, Цитата:
, что base64 и uuencode как-то не сильно...

kms писал(а) 10. Июня 2007 :: 09:46:


Про пункт 2 ничего сказать не могу. В своих базах не применяю.
По пункту 3 просто всегда добавляю к строке один символ ( 'z') при  чтении из файла
при записи игнорирую последний символ.
4. для dbf файлов макс размер = 80*100 000 байт ~ 8 Мб.
Есть вроде еще принипиальное ограничение на длину OLE строки или OLE строки для
1с но этой величины не достигал( у нас стоит ограничение на размер файла 400Kb).

trdm писал(а) 12. Августа 2007 :: 21:26:

А ты посмотри на соседнюю ветку. Там vip выкладывал конфу с активиксом для отображения картинок с помощью gflax.dll. Ссылка на библиотеку GFLAx также имеется.

Ну у vip'a спроси, думаю, что не откажет.

vip писал(а) 13. Августа 2007 :: 05:43:

0 >> 0x00, 1>>0x01 и т.п?
В принцыпе понятно.

trdm писал(а) 12. Августа 2007 :: 21:26:


пиши в личные сообщения с указанием куда слать ( только найти еще надо где это лежит )