Отправлено: 29.12.15 20:00. Заголовок: Хранение *.zip файлов в базе ?

Сделал запись zip-файлов в мемо-поля базы (драйвер DBFCDX).
Файлы записываются без ошибок, только после извлечения из мемо-поля - архив становиться "битым" и не распаковывается.
Как победить это ?
Или нужно другую базу использовать ?

 Отправлено: 16.09.23 13:39. Заголовок: PSP пишет: А почему..

PSP пишет:

цитата:

А почему hb_memoread? Она ж вроде для текстовых файлов предназначена, не? Иконки и бмп - не текстовые.

Самое простое... Давно использую.

В хХарборе есть функции HB_Base64DecodeFile() и HB_Base64EncodeFile()
А в Харборе как они называются ?

 Отправлено: 16.09.23 13:44. Заголовок: Andrey пишет: В хХа..

Andrey пишет:

цитата:

В хХарборе есть функции HB_Base64DecodeFile() и HB_Base64EncodeFile()

Свои напиши..

 Отправлено: 16.09.23 14:13. Заголовок: Особо и писать не на..

Особо и писать не надо

 
 #translate _Base64EncodeFile( <cFile> )           => hb_Base64Encode( hb_MemoRead( <cFile> ) ) 
 #translate _Base64DecodeFile( <cFile> , <cBuff> ) => hb_MemoWrit( <cFile>, hb_Base64Decode( <cBuff> ) ) 
 или 
 #translate _Base64DecodeFile( <cBuff> , <cFile> ) => hb_MemoWrit( <cFile>, hb_Base64Decode( <cBuff> ) ) 
 

 Отправлено: 16.09.23 17:23. Заголовок: SergKis пишет: Особ..

SergKis пишет:

цитата:

Особо и писать не надо

Спасибо !

 Отправлено: 24.09.23 13:01. Заголовок: Для хранения иконок,..

Для хранения иконок, звуков и прочих двоичных данных давно придуманы "ресурсы", которые зашиваются в тело exe-шника программы.

Погуглите в сторону hb_gtInfo( HB_GTI_ICONRES, "icon_name" ) - наверняка, это окажется удобнее, чем бинарный файл переводить в Base64 и внедрять его в код программы.

 Отправлено: 24.09.23 14:54. Заголовок: Sergy пишет: это ок..

Sergy пишет:

цитата:

это окажется удобнее, чем бинарный файл переводить в Base64 и внедрять его в код программы.

Это просто ещё ОДИН способ хранения ресурсов.
И не я его придумал, посмотри библиотеку МиниГуи там есть уже такое.
Например TsBrowse.

Sergy пишет:

цитата:

Для хранения иконок, звуков и прочих двоичных данных давно придуманы "ресурсы", которые зашиваются в тело exe-шника программы.

Не всегда это удобно, ехе-ник сильно раздувается. У меня уже 20 Мб ресурсов, всякие иконки для программы.
Это много и неудобно, лучше иметь отдельную отдельную библиотеку myResource.dll для таких целей.
А печатные формы формата xml вообще держу в dbf с мемо полем, чтобы не было кучи файлов.

 Отправлено: 24.09.23 20:35. Заголовок: Так если проект сост..

Так если проект состоит из одного exe-шника, то ресурсы разумнее хранить именно в нем. Если это много exe-шников, которые используют одни и те же данные, то есть смысл их выделить в отдельную dll

 Отправлено: 24.09.23 20:39. Заголовок: Andrey пишет: У мен..

Andrey пишет:

цитата:

У меня уже 20 Мб ресурсов

Ты ж с готовностью собрался загонять 350Мб данных в память, причем бесконтрольно, а 20Мб, которые будут под контролем менеджера памяти, тебя смущают. Странно...))

 Отправлено: 24.09.23 21:42. Заголовок: Pasha Если это много..

Pasha

цитата:

Если это много exe-шников, которые используют одни и те же данные, то есть смысл их выделить в отдельную dll

Или поместить несколько иконок в тело lib и не думать об этих иконках. Перетащил в ресурсы нового exe их ? Или та ли версия dll у клиента, и с теми иконками.

цитата:

Это просто ещё ОДИН способ хранения ресурсов.