Здравствуйте все. Я далеко не специалист в тех темах которые обсуждаются на этом форуме, но хочу научиться. Введение (извиняюсь, что долгое) Есть необходимость сделать конвертер между старой БД и какой либо современной. Старая БД, а точнее ее СУБД были созданы, если не ошибаюсь в ~1992 году в Литве в Каунаском институте. Ее структура напоминает реляционную и способна хранить большой объем данных в пределах 1 мегабайта. Есть конвертеры в DBF. Один конверет создает простой линейный (с избыточными полями) DBF и съедает примерно в 5-10 раз больше места диске (про объем это я так, это не тема вопроса). Другой конвертер создает 3 DBF связыных и потребляет в 3-5 раз больше места. Необходимость создания своего конвертера возникла из-за большого различия в целях разработчиков выше упомянутых конвертеров и нашими. У этих разработчиков конвертеров либо нет СУБД и систем полученя статистики по БД, либо она есть но с багами, так как не имеют тестеров, а из-за вопроса финансового выживания нет времени на наши запросы (к тому же удаленно понять причину ошибки они конечно не могут). Старая СУБД могла себя хорошо чуствовать на ОС до win98 (субд не использует расширеную память, т.е. только первый мегабайт ей доступен), с переходом на XP обнаружили что не вся статистика по БД корректно работает, сидим под эмуляторами и косо смотрим на Vista. А также отсутствия поддержки у нас по программисткой части. Поэтому я решил "спасение утопающих, дело рук самих утопающих". Старая БД, это по сути текстовой файл, но сжимаемый собственным "архиватором" примерно в 3 раза. Рядом с файлом БД всегда присутствует файл описывающий его структуру. Я пролистал exeшник архиватора в просмоторщике Far`а и в конце нашел "Borland C++ 3.0" (в нете сейчас можно найти только по 3.1). Задача. Если рассмотреть задачу, то выходит: нужно сделать конвертер в обе стороны; нужно выбрать подходящую по задаче современную СУБД; начать работу по автоматизации получения статистики и так далее и тому подобное. Первый шаг, конвертер. После его создания смогу лучше выбрать современную СУБД. Но не знаю с чего начать. Либо искать литературу по расшифровке самой БД для определения алгоритма сжатия, либо депомпилировать этот старый архиватор. Прошу помогите советом и литературой. Естественно у некоторых возникнет мысль просто использовать старый архиватор и не греть голову, мы это уже проходили, во время работы (а она должна быть выполнена быстро) возникает много головной и все это приходиться делать в эмуляторе, потом с него перебрасывать каким либо образом на реальную машину, так как архиватор без установленой СУБД не работает. Эта структура БД будет еще использоваться очень долго, поэтому конвертер нужен будет постоянно. Всем огромное спасибо за помощь. P.S. Небольшой пример прилагаю.
Я особо не вникал, но ты знаешь структуру этой базы (таблицы и ключи) на верхнем уровне? Если да, то почему бы не попытаццо прочитать ее запись за записью и перезалить в новый формат? У этой базы (интерфейса) есть такая возможность? Может, там библиотека какая или что?
А почему бы не перевести все в DBF, а потом не залить все в человеческую БД и не компостировать мозги? Или я что-то не понял? Как-то сумбурно все.
2 PSR1257 Прочитать запись за записью можно в не сжатом виде, а для этого пользователь должен все перевести в не сжатый вид. Учитывая, что этих файлов БД очень много, процесс получается долгий (прога по досовски сжирает весь проц). В сжатом виде если бы прочитать то выходит меньше головняка для пользователя, а значит меньше времени и ошибок. Обращатся к СУБД для передачи данных, ну ты сам понимаешь, ее нужно держать на виртуалке и т.д и т.п. И еще одна у меня мысль в голове крутится, в этих текстовых базах иногда встречаются "не клавиатурные" символы, может это из-за своего архиватора. 2 perez Да может я сумбурно объяснил. Но эту конвертацию нужно будет выполнять быстро и часто. Представь, весь мир будет работать на этой старой БД, а мы хотим на новой и поэтому нам прийдется конвертировать при передачи или поступлении, довольно таки часто. Если бы это было нужно только один раз, тогда да, в DBFки перекинули и потом во что-нибудь типа MySQL или PostgreSQL (хатя нам такие СУБД могут быть излишними, ведь оперировать придется только 3-6 милионами строк реляционной БД, это при самых громозких задачах). В общем, понять алгоритм, мне все одно прийдется, так или иначе. конвертер нужен прямой со сжатого вида, он поможет понять серию проблем. обходные пути (более простые) я уже искал с 2004 года, результаты не блеск, нюансов много. По сути мне нужна только литература и наводки по определениям.
Т.е. непременно нужно продолжать работать со старой базой и иметь в то же время возможность работать с ней "по-новому"? Я опять-таки не стороннег делать "как лучше на первый взгляд". Проблемы с памятью в DOS? - > попробуй DOS-extender. Не уверен, но вроде старые DOS-расширители были способны обработать экзешник и перевести его функциональность в DPMI - а это точно поддерживаеццо xp. Т.е. думать вообще не надо. Вызовы int 21h и возможно int 10h extender эмулирует как и выдачу блоков памяти. Если прога работает с своей базой через свой драйвер или как там, то проще написать такой же интерфейс к новой SQL чем пытаццо синхронизировать из нового функционала транзакции, блокироффки и чем там еще.
wmd772 1. Насколько я понял Вы не являетесь держателем БД, соответственно такие Ваши регулярные действия должны быть согласованы с теми кто поддерживает работу БД, а они вероятно будут против т.к. это увеличит нагрузку на сервер(ы) в разы. 2. Как вариант можно попробовать стянуть всю БД один раз, а затем скачивать только новые транзакции, но для этого должен вестись лог транзакций. Не совсем понял поддерживает ли БД SQL. Если да, то можно штатно выгружать записи в файл представляющий собой инструкции на языке SQL (запрос что то типа SELECT * INTO OUTFILE...) и соответственно затем штатным способом загружать их в новую БД. Соответственно никакие конвертеры будут ненужны.
Есть тулзы для автоматического определения алгоритмофф - например можно поискать характерные константы MD5, etc - и она тебе скажет (или не скажет) что там внутри. Типа PKLite или что там было... Ну или найди в дизассемблере процедуру сжатия и смотри какие константы там используюццо -> google it.
2 pas подожди не спеши 1. Я не держатель БД и очень хотел бы знать где держатели этой БД. Так же интересно, почему проект не поддерживается, ведь это заказ министерства СССР. Руководителями проекта были E.Карчяускас и Ю.Юодис, это фирма ЗАО "STRELE" и все авторские права принадлежат ей, версия продукта V 3.1(1994.10.30). Я бы с ними согласовал все вопросы, но о них уже никто ничего не знает. А про нагрузку на серверы, это не верно, СУБД не сетевая, когда ее писали, расчитывали на архивацию копий на флоппи диски. Фирму эту в инете найти не могу. Чесно, может перекурите и почитаете пост снова? 2. Перечитать первый пункт и мой первый пост. 3. СУБД писалось в 1994 году, это конечно странно что она не знает sql, но с другой стороны это CCCP, а точнее Латвия. До сих пор Чехословакия пишет проги под BDE, dbase и pardox. Но все же спасибо, поштудирую документацию еще раз на совместимость с sql, может проглядел. Хотя, если прочесть в самом начале "В СУБД L реализованна структура данных соответствует структуре данных языка С, т.э. ее идеология наиболее похожа на все большую популярность заваевывающую СУБД VISTA." сомнения увеличиваются. 2 PSR1257 Спасибо попробую, погуглю.
