восстановление удаленных записей

[Boris]

Пришлось столкнуться с проблемой восстановления удаленных записей из таблицы. Пришлось писать программку на коленке, т.к. в интернете нашел только скрипт на MB от 1999 года.
Какие есть пути решения таких проблем? И на сколько они вообще актуальны, учитываю нынешние цены на носители информации?

[asgs]

Если у записи в таблице не было графики, то берем любой редактор DBF и натравливаем его на DAT-файл таблицы и восстанавливаем удаленную запись. А вот если была еще графика, то тут мне самому интересно, как можно восстановить запись полностью.

[Boris]

Естественно с графикой. Что за таблица MapInfo без графики? Про то, что DAT - это DBF DBase III, найти за полчаса поисков не сложно.

[Дмитрий Барышников]

Вообще-то при удалении записей MI помечает их удаленными, но не удаляет фактически. После выполнения операции паковки записи удаляются "насмерть".
Вы паковали?

[Boris]

Если вопрос ко мне, то естественно нет. Упаковка - это копирование в новую таблицу с пропуском записей, помеченных как удаленные.
Что же до самой задачи. То попалась таблица, в которой число удаленных гео-объектов не совпадало с числом удаленных атрибутивных записей. И кроме того, в таблице был построен пространственный индекс, а вот его то утилита Recover 1.63 от 1999 года обрабатывать не умеет. Равно как и часть ее предположений относительно размерности бинарных данных отличается от действующих величин.
PS
Я не узнать хотел как делать. Я хотел понять на сколько задача встречается в природе, что бы тратить время на ее приличную алгоритмизацию, в основном на причесывание утилиты к виду достойному ее обнародования (без корыстных устремлений). На коленке она работает - восстановила таблицу в 60000 записей. Голову за праздники я этой задачей размял. Если задача имеет место быть, а я по себе знаю, как обидно утратить данные, то я не торопясь дойду до описания алгоритма статьей, если нет - уберу утилиту до следующего неприятного случая.
PSS
Как оказалось в формате предусмотрены две возможности хранения координат объектов - 2 байта и 4 байта. Во всех опробованных таблицах было 4, из которых значимыми были только 30 бит. Но в списке возможных типов данных явно оставлены пропуски для геоданных большей размерности. Видимо 8 битных. То, что они так и не появились, позволяет предположить, что видимо такая размерность была посчитана избыточной. А жаль. Тогда все разговоры о точности и границах таблиц можно было бы забыть.

[gamm]

Как оказалось в формате предусмотрены две возможности хранения координат объектов - 2 байта и 4 байта. Во всех опробованных таблицах было 4, из которых значимыми были только 10 бит.

это не опечатка? 10 бит - это всего 1024 возможных значения, а их по факту вроде больше.

[Дмитрий Барышников]

Я не узнать хотел как делать. Я хотел понять на сколько задача встречается в природе, что бы тратить время на ее приличную алгоритмизацию, в основном на причесывание утилиты к виду достойному ее обнародования (без корыстных устремлений)

За MI не скажу.
В ArcGIS используем версионность с историческими версиями, а для шейпов и mdb - на сервере - теневое копирование (причем как на WIn так и на Linux).
A MapInfo SpatialWare или OracleSpatial + MI поддерживают исторические версии?
P.S. В общем восстановлением не ГИС софт занимается, а системный.

[Boris]

Как оказалось в формате предусмотрены две возможности хранения координат объектов - 2 байта и 4 байта. Во всех опробованных таблицах было 4, из которых значимыми были только 10 бит.

это не опечатка? 10 бит - это всего 1024 возможных значения, а их по факту вроде больше.

вы правы, конечно же 30 = 4*8 - 2 разряда. Вот откуда и вылезает размерность в границах карты в 1 000 000 000, как уже писалось. Хотя различие в размерности между 10**9 и 2**30 составляет 1:1.073741824, так что может все же не деление, а сокращение лишних степеней 2-ки.