Paradox + TTables

Нужно ли делать Table1->Active=false при завершении работы?
А то кочяк какой-то - время от времени данные в базе слетают. Таблицы Paradox7

0

pincet, таблицы парадокса и фокс про не то, что нужно, а обязательно надо закрывать, иначе могут быть много неожиданных неприятностей: и индексы летят иногда, и временные таблицы остаются... и вообще это правило хорошего тона в программировании ИМХО:

что-то создал - удали, что-то открыл - закрой...

0

т.е. при закрытии формы все TTables->Enabled=false?
В смысле TTables->Active=false

0

pincet, у тебя код должен выглядеть всегда примерно так:

0

Вопросик небольшой - нельзя в этом случае полагаться на деструктор ~TTable?

0

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

0

Блин, совсем худо. Таблицы закрываю - время от времени записи в разных таблицах пропадают. Если саму среду C++Borland не закрывать - все ОК, если перезапустить - иногда откатывается на старые данные, причем непредсказуемо Послезавтра отдавать софтину - печально. Есть мысли какие?

0

pincet, значит из-за некорректной работы записи просто не записываются, хотя я такое не встречал в файловых базах... разве что после записи данных ресетом винду перезапустить... еще посмотри на БДЕ-шные функции, там есть такие, что принудительно записывают данные в файл таблицы... а у тебя после закрытия проги остаются файлы со странными названиями?

0

Да здесь дело похоже в кэшировании. Ибо если из IDE не выходить - все OK. Как только перезапуск IDE - через раз проблемы. Остаётся надеяться, что чистая апликуха будет пахать

0

pincet, вы не забывайте о законах Мерфи... поэтому надо искать косяки в коде

1

Простые меры предосторожности при отладке приложения, работающего с парадоксом

В дизайне:
1. Использовать TDataBase и все операции проводить через него.
2. Использовать динамическое создание алиаса и привязку его к TDataBase перед открытием БД
3. Не держать открытым TDataBase (и ни один набор данных как следствие)
4. Не использовать связки мастер-детал для 2-х и более TTable - высокий % слета индексов при аварийном завершени программы. Если шибко надо, то через спец.мастер-таблицы, предварительно копируемые в привэйт-каталог.

При запуске:
1. Убить все *lck
2. Если при последнем запуске было падение индексов (Out of Index и др) или разрушение таблиц (corrupted table), то починить или пересоздать таблицы (индексы)
3. Не запускать приложнение из-под Делфи. Только "build project" с последующим запуском из Windows или оболочки

Если кому-то покажется очень морочливым и трудноисполнимым - забыть про парадокс и BDE !

Добавлено через 14 минут
Дополнительно.
Почти всегда виновник всех бед при работе с парадоксом - TTable. При открытии таблицы (таблиц) BDE открывает также индексы и создает файл блокировок (lck), начиная отслеживать изменения. Т.к. при отладке приложения использование таблицы всегда идет в конкурирующем режиме (даже если в дизайне таблица закрыта, сама Делфя "держит" ее, то при любом практически аварийном завершении программы (а при отладке это абсолютно нормальная ситуация, возникающая по сту раз на дню), высока вероятность повреждения индексов из-за незакрытого нормально (и не срошенных кэшей) TTable. Если используется связка мастер-детал и были выполнены вставка или удаления, вероятность слема многократнго увеличивается. Поэтому зависания как программы, так и всей среды Делфи (в 6-й по крайней мере доставало как следует).

Если нет возможности ухода от парадокса (а это, к сожалению, бывает. Приходится бороться, не отказываться же от заказчика, часто готового нормально платить за копание в г...не), то просто переходите на TQuery и правку в модальных формах через не DB-aware контролы, т.е. по Клиент-серверной идеологии. Если же заказчик требует редатирование в "манере экселя", т.е. в гриде, то можно решить имитируя строку сетки с помощью панели и эдитов. Конечно, морочливо, но можно в конце концов написать собственную компоненту, которая будет это делать в ЛЮБЫХ гридах . Поверьте, эти затраты многажды оправдают себя при отладках/внедрении/сопровождени проектов.

1

+100
Подскажи, происходит ли Post() при нажатии в DBGrid "стрелка вниз", или это Insert()
Блин, не совсем то хотел спросить - происходит ли Post() автоматически при нажатии "Вниз" на последней строке?

0

При нажатии стрелки "вниз" на "чистом" TDBGrid (т.е. не определены обработчики событий и грид ведет сетя "стандартно", при это ессно НД редактируемый и грид не в режиме ReadOnly

Если запись перед стрелкой была последней, то в сетку добавляется пустая строка в конец, курсор переходит туда, а датасет переводится в режим dsInsert, при этом если в записи есть поле типа автоинкремент и VCL+DAC+Сервер поддерживают автополучение счетчика, то в поле счета появится новый ID (хорошщо видно в акцесе). Можно вводить в ячейки грида - поля датасета. Если пользователь ничего не ввел (и не пытался), а просто нажал стрелку вверх, то эта пустая строка автоматически удалится - НД ничего не изменится. Если пользователь что-то ввел (хоть один символ хоть в одно поле, то датасорс "свистнет" датасету и тот начнет отработку и завершит ее постингом в случае корректных данных либо AV, если программист не предусмотрел обработку события BeforePost)

Аналогично отрабатывает кнопка Insert (Ctrl+Insert не помню точно), правда пустая строчка возникнет
не в конце сетки, а в том месте, где был нажат кнопка, но полс епостинга запись все равно "улетит" в конец.

Если полагаться только на стандартное поведение грида, то работа с приложением превратиться для пользователя в кошмар. Его ожидают непреднамеренные потери данных и "нечаянные" искажения их.

Добавлено через 1 минуту
А вообще читайте справку по TDataSet - она написана превосходно !

1