DB
должно работать обычно
Size: a a a
2020 December 10
ДT
длл от текущей версии я не смог подключить к коду
AZ
ну 7zip вроде еще пару более современных методов сжатия умеет, а так по идее они вроде совместимы
DB
может только что с правами на доступ к 7z или к файлам какой-то косяк
DB
процесс будет порождаться с правами порождающего по идее и хз что там у вас с правами
YA
вот хз, уже как 2 месяца ищем проблему
ДT
вы храните архивы в базе? вот вы суровые парни :)
а почемуб и нет?
AZ
я бы переделал на встроенный в дельфи зип, у меня с ним проблем небыло
YA
получается каждая сессия вызывает этот 7ZIP.exe как бы не правильно это
DB
а почемуб и нет?
можно. но сурово :) я видел как-то такую реализацию, и она очень не понравилась
AZ
а почемуб и нет?
зачем? база пухнет, бэкапы и восстановления тормозят, эти поля не индексируются и вообще с точки зрения работы с данными в БД смысла не имеют
YA
тут мой коллега присоединился
AZ
Ну так добро пожаловать коллега :)
OT
Всем привет!
ДT
зачем? база пухнет, бэкапы и восстановления тормозят, эти поля не индексируются и вообще с точки зрения работы с данными в БД смысла не имеют
зип архив хмл весит в базе 1 метр, разворачивается в базу, заполняя таблицы больше чем на 10 метров
YA
в общем большая часть шишек по 7ZIP ему досталась))
AZ
зип архив хмл весит в базе 1 метр, разворачивается в базу, заполняя таблицы больше чем на 10 метров
храни в БД ссылку на относительный путь на файловой системе, чтобы если что файлы можно было бы легко переложить в другое место или вообще разнести
AZ
хранение архивов в БД это зло, бить по рукам! :)
DB
я бы переделал на встроенный в дельфи зип, у меня с ним проблем небыло
мы от встроенного как раз отказались. есть несколько проблем:
1. на 32х можно легко нарваться на oom
2. баг в зип или 7z либе приводил к краху всего процесса. внешний бинарь работает намного стабильнее
1. на 32х можно легко нарваться на oom
2. баг в зип или 7z либе приводил к краху всего процесса. внешний бинарь работает намного стабильнее