Подскажите кто как борится с мусором в таблицах появляющемся при отключении питания

В решениях толковая функция есть точно!
Тока не помню где..... поискай!

ООО!
Нашел!
www.foxclub.ru
Оно самое......

Хотя там исче масса чего есть по этому поводу....
Смотря че те надо!



Отредактировано (30.03.05 18:03)

UPS рулит
да и резервное копирование оччччень помогает...

2 vlad - сложна не согласиться!

Резервное копирование, UPS это все понятно. А если ты ставиш совт кучу пользователям, а среди них немного сознательных, большенство не заботится о выше перечисленных вещах. Вот и приходиться извращаться.

В решениях я подходящего не нашел.

2Shardim

Цитата:

а среди них немного сознательных

позаботься сам о програмном бэкапе

а вообще такие сами виноваты...

Hi Shardim!

Бороться надо с отключениями питания, а не с мусором в таблицах. Ибо это бесполезно. Тебе кстати ещё везёт что только мусор в таблицах возникает - часто при такой проблеме полностью слетают индексные файлы (до длинны в 0 байт), иногда сама таблица может безвозвратно испортится.
Ты ещё попробуй программно бороться с психом который ходит и кувалдой компы ломает Тоже оч-чень увлекательная задача

2 Shardim:

Цитата:

кто как борится

1. Найти того диверсанта и прочитать ему лекцию о зимовке раков (с обещанием в дальнейшем провести практический лабораторный опыт выдергивания шаловливых рук)
2. Поставить UPS, если диверсанты не ЗдаюЦЦа...
3. Использовать таблицы в DE форм, а не открывать их при помощи USE. В сессии данных тогда создаются курсоры (таблицы не используются напрямую как в случае с USE). Или использовать CursorAdapter'ы, что появились в последних версиях VFP. Также неплох выриант и с RemoteView.
4. Использовать буферизацию 5 уровня с TableUpdate(.T.,.T.) или транзакции с RollBack'ом в случае неудачи. В 9-й версии транзакции данных поддерживаются свободными таблицами (в версиях постарее - таблицами, включенными в контейнер БД).

P.S.
Обновить, по возможности, версию фокса, если используется старая. Чем старше версия, тем все-таки надежнее. Хотя, по большому счету, не от версии все зависит, а от искусства как такового. Пусть человек думает, а компьютер (или фокс) делает. Когда наоборот - все выглядит куда более запущено



Отредактировано (31.03.05 02:40)

2Alex Roublev

Цитата:

Найти того диверсанта и прочитать ему лекцию о зимовке раков

IMHO бороться надо не с человеком, а с явлением как таковым. Т.е. применять метод административного воздействия, направленый на искоренение такого способа действий в корне.
I.
1.Пишется инструкция о работе с программой и утверждается у руководства (с красочным описанием "чего может быть если...")
2.Все ознакамливаются с инструкцией под подпись
3.В случае установления нарушения оной -- кляуза начальству и как следствие депремирование нарушителя (оччччень действенно: много не надо одна,две кляузы и весь офис знает инструкцию на зубок и цитирует ее друг другу в курилке :gigi

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

Под Нетварью и Виндовсе у клиента, если последний падает,
иногда появляеться "плавающий" мусор. Бороться можно: или перекопировать
таблицу на сервере или перезапустить сервер (последнее - догадка, не проверял:shuffle

Люди остановитесь. Все что вы написали как это предотвратить понятно. И административные меры и технические, кстати спасибо Alex Roublev. Ну вот появился мусор, покричали потопали ногами, копии как всегда нет, а востанавливать то надо. Да понятно, что всю базу не востоновиш, ну хотябы ее часть.

таблицу показать можешь?
в каком она виде?

1. Сервера/раб. станции/ коммутационное обор. = все должно висеть на UPS
2. Ежедневный бакап даты
3. Разработка регламента работы с применением адм.ресурсов (в том случае если ситуация неоднократная)
4. что касательно проги, ну вот самое простое что приходит в голову делаешь два цикла, первым идешь по заголовкам, для выявления типа хранимых данных, во втором, вложенном цикле проверяешь наличие в поле на соответствие типу. Далее как сам хочешь, можешь сделать еще одну таблицу, в которой будут храниться recno() удаленных записей,(это для более корректного востановления строк, если напортачишь)в переборе 2-го цикла проверяешь на соответствие, если одно нет= бахаешь строку, можешь перед этим вывести ее на просмотр с диалогом да/нет...

Hi Shardim!

Цитата:

а востанавливать то надо

Руками, всё делается - руками.
Структура заголовка подробно описана в хелпе - и в принципе можно её взять у любой имеющейся копии (подправив потом "по факту" счётчик записей), "мусорные" (т.е. безвозвратно испорченные) записи удалить можно и потом - просматривая базу глазками - обычно в текстовых полях это выглядит как "прямоугольнички/штришки" или всякая "псевдографика" (в зависимости от того занулился ли блок или заполнился мусором).
Т.е. схема в общем простая
- в hex-редакторе проверить заголовок, и если он убит - взять из "корректной" (пусть и старой/пустой) копии
- посчитать физическое число записей (взяв размер dbf, отняв размер заголовка и поделив на "размер записи") - записать в соответствующее поле в заголовке.
- если есть cdx - "открепить" его (что может вызвать сложности, если у таблицы были первичные ключи) - тут тоже поможет правка заголовка в hex редакторе, а потом VALIDATE DATABASE RECOVER (чтоб удалить инфу о индексах из dbc).
- теперь можно открывать из фокса, и смотреть в browse - попутно удаляя мусорные записи.

P.S. Естественно что всё это нужно делать на отдельной копии файлов!

Hi Alex!

Цитата:

3. Использовать таблицы в DE форм, а не открывать их при помощи USE. В сессии данных тогда создаются курсоры (таблицы не используются напрямую как в случае с USE).

Это не совсем так, я так понимаю ты перепутал LocalView с DE...

Цитата:

Или использовать CursorAdapter'ы

Это по сути те-же LocalView и есть - только более управляемые. Это может помочь.

Цитата:

Также неплох выриант и с RemoteView

с Remote - плох. Медленно, куча геморроя с настройкой коннекции к "родной" базе - отсутствие в ODBC драйвере поддержки массы нововведений последних версий...

Остальное вроде вопросов не вызывает

Привет, Игорь

Цитата:

перепутал LocalView с DE

Да

Цитата:

с Remote - плох

Точно. Много геморроя с RemoteView! По памяти перебирал имеющийся арсенал способов, нацеленных на корректную запись данных во избежание накопления "мусора" в рабочих таблицах.

Привет, Влад

Цитата:

IMHO бороться надо не с человеком, а с явлением

Да ясное дело. Это ж шутка юмора. Явление внезапного отключения электроэнергии форс-мажорное обстоятельство. Внезапно как цунами и неотразимо (без UPS, конечно же) как проливной дождь. У нас учреждение висит на единой подстанции с молокозаводом, стоящим неподалеку. Когда на подстанции "что-то" происходит раз-два в год, то побороть сие явление своевременно никогда не представляется возможным. Правда жизни...

Параллельно со своей непосредственной работой трудился некоторое время в архитектурно-дизайнерской фирме. Рисовал в Macromedia FreeHand планы городских кварталов под реконструкцию, собирал с текстами в единые проекты-альбомы. На том же этаже работала государственная проектная контора. Распределительная коробка была в коридоре. Так вот подходит однажды сотрудница того отдела и вырубает в силу нужд своего отдела все рубильники в этой коробке. У меня как раз полтора часа работы "свалились" в один миг. Воспитательную беседу провели. А что толку - работа все равно "псу под хвост".

Так что бывает вина не своих сотрудников, а другой организации, от которой зависишь, так сказать, энергетически.

Hi Alex!

Кстати "безопасности" (в плане целостности файлов) использование VFP ODBC не добавит ни на каплю... По сути то способ доступа через ODBC ничем не отличается от прямого (в связке драйвер-файл, не между драйвером и клиентом!). OBDC драйвер - это как "маленький фокс" - со всеми теми-же вытекающими последствиями. И даже ещё хуже - т.к. контроля над ним значительно меньше будет - и синтаксис к тому-же ограничен... И исполняется его код на той-же самой машине где и код клиента.
Вот если сделать "посредника" другого типа - COM сервер живущий на другой машине (на том-же сервере где и файлы данных), и доступный через DCOM/COM+/WebService - и обеспечить UPS-ом хотя-бы этот сервер - тогда надёжность конечно сильно повысится - это по сути будет уже клиент-серверное решение (ессно что и программировать под него нужно исходя из идеологии клиент-сервера).