Если закрыть приложение убиванием процесса через диспетчер задач, или при запущенном приложении пропадает свет, при следующем запуске почти все открытые таблицы стают corrupted. То есть, при «неожиданном» закрытии программы запись в таблицы не велась, таблицы были просто открыты с помощью USE … EXCLUSIVE.

Восстановить таблицы – не проблема. Но это не работа, каждый раз, когда «что-то пошло не так» звать системщика и восстанавливать таблицы. Можно ли как-то защитится от этой ситуации? После любых изменений в таблицах делать FLUSH, или еще что-то в этом роде?

Конечно можно - как минимум не открывать их EXCLUSIVE ... а как максимум - вообще уйтить от dbf

Ну вроде как FLUSH решает проблемы.
Ну и элементарные поломки таблиц приложение должно само исправить без админов.
Насколько помню наиболее частая ошибка рассогласованность фактического кол-ва записей и указания в заголовке. Пара десятков строк кода лечит эту проблему.

AndyNigmatec
Конечно можно - как минимум не открывать их EXCLUSIVE ... а как максимум - вообще уйтить от dbf

Где мог, ушел, но программа большая, переписывать долго, есть PACKи, ZAPы. Поэтому что осталось, то только DBF и только EXCLUSIVE.



Исправлено 1 раз(а). Последнее : spammail_88, 28.12.19 10:28

Taran
Пара десятков строк кода лечит эту проблему.

Не подскажите, где я могу найти пример? Или, хотя бы, что искать.

Там обычно простая ошибка - количество записей отличается от счетчика в заголовке. Когда-то написал процедуру средствами самого фокса исправления. Если найду - выложу

ЗЫ Нашел. Полная функция открытия дбфки со всеми проверками и исправлениями. Конкретно правит функция NOT_DBF



Исправлено 1 раз(а). Последнее : Burn, 28.12.19 15:04

Исправлено 3 раз(а). Последнее : Crispy, 31.12.19 10:43

Опять криспа бредит...

Исправлено 2 раз(а). Последнее : Crispy, 31.12.19 11:39

() Что при помощи SELECT/INSERT работай с таблицей, что SCATTER/GATHER - все равно фокс физически открывает DBF-ы как обычные файлы, как просто наборы байт, читает/пишет в них низкоуровневыми командами ОС, при вырубании питания компа или при разрыве сетевого соединения файл может быть как угодно испорчен. И "взрослые" БД также устроены, как надстройка над файлами ОС, и также "падают" при выключении питания (разве что сетевые проблемы не ломают БД).

А так да, напрямую в Grid изображать писать таблицы лучше не надо, да так и не выходит обычно, видеоизображение таблицы далеко от ее реальной структуры.

AndyNigmatec
Конечно можно - как минимум не открывать их EXCLUSIVE ... а как максимум - вообще уйтить от dbf

еще не использовать Memo поля.

Crispy

Часть текста скрыта

Закрыть

Simple777

Crispy

Часть текста скрыта

Закрыть

Часть текста скрыта

Закрыть

Не так страшен черт...
Порчу дбф легко обнаружить и даже исправить, а вот порча cdx гораздо более зловредна и случается гораздо чаще.
Ее так просто не обнаружить, а вылечить помогает только гильйотина.

В чем проблема с cdx?
Взял из копии и запустил reindex.
Насчёт "чаще" тоже не согласен.

reindex когда не все совсем наепнулось. Структуру надо держать в проге, но обычно выходит так, что ищут последнюю копию БД, хоть что-то

УПСы, конечно, сильно упростили жизнь, но в свое время при сбоях питания cdx слетал практически гарантированно, а dbf иногда "выживал". Специально статистику не вел, но навскидку соотношение примерно 5 к 1. Хуже всего то что не известно слетел он или нет. А после недели работы с битыми индексами такие черти вылезают - мама не горюй. К тому же переиндексация операция не такая дешевая. До сих пор живет у меня проект в котором сия процедура занимает от 2х часов и более.

Taran
В чем проблема с cdx?
Взял из копии и запустил reindex.
Насчёт "чаще" тоже не согласен.

Проблема в том что испорченный заголовок dbf в 8/9 фоксе виден сразу (SET TABLEVALIDATE для того и был сделан), в более старых - хоть и не виден, но не мешает работе до того как потребуется добавление новых записей или обращение к "несуществующим". Испорченный целиком блок в файле (кроме первого, с заголовком) - ну это "обнулённые" или "замусоренные" десяток-другой записей (в принципе это можно определять программно). Порча cdx гораздо сложнее определяется, а приводит к тому что некоторые записи то видны то не видны (в зависимости от того используется ли индекс для их поиска или нет), плюс большая вероятность "зациклиться" - т.е. при том же scan или skip-ах "перескакивать" на уже пройденную запись. Т.е. это ошибка гораздо более коварная, т.к. не очевидна.
Да, взять из копии и реиндекс это вариант - но надо и копии какие-то где-то держать (из обычного бэкапа, или специально сконструированные "только cdx для пустых таблиц") и при изменении структуры не забыть обновить эти эталонные cdx. Ну и см. п.1 чтобы это выпонить нужно сначала определить что это НУЖНО делать При каждом запуске - чересчур накладно.
Частота порчи - вопрос интересный. Полагаю что относительно простые "логические" сбои в файлах - то самое рассогласование счётчика в заголовке dbf и размера файла, "пропажа" ссылки на мемо-поле, отсутствие в cdx информации про новую запись, или устаревшие данные о существующей (по сути их причина - одна логическая операция записи "размазанная" по нескольким файлам или частям одного файла) для dbf имеют менее разрушительные последствия.
"Физическая" же проблема с файлом - обнуление или "замусоривание" сектора гораздо более разрушительны, и без специализированных инструментов восстановления их не исправить. При этом ситуация получается обратная - cdx починить проще (взяв из копии, или даже вручную пересоздав командами INDEX - хотя там есть небольшая морока с флажком в заголовке dbf), а вот в dbf что пропало - то пропало навсегда.

Igor Korolyov
хотя там есть небольшая морока с флажком в заголовке dbf

Разве ж это морока?
Первый USE сбрасывает флажок, генерируя ошибку 1707.
Повторный USE нормально открывает таблицу.

Хотя, действительно, многие до последнего правили этот байт в файле с помощью FWRITE().

Насколько помню индексы и связи несколько зафиксированы в самой БД. Т.е. простое удаление файла cdx, сброс флага в dbf и пересоздание индексов несколько сложнее чем взять из архива файл cdx правильной структуры и выполнить reindex.