Господа, имеется вопрос.

Ситуация следующая : есть приложение, которое активно используется пользователем. Пользователь использует его как днем, так и ночью.
Т.е. ПК оставляют включенным на ночь. В некоторое время (в БД есть таблица "заданий") стартуют задания, выполняются и сохраняют данные в БД.
Так вот, система успешно работала более полугода. В данный момент, выполнение первого ночного задания приводит к "зависанию" и потери данных.
Что интересно, не всегда...есть дни, когда все работает на ура. Днем таких проблем не бывает.

Если посмотреть на одну из таблиц, в которую происходит запись, то вижу следующее :
<ID таблицы> 22123,22124,23009

Т.е., насколько я понимаю, запись в таблицу БД была, но COMMIT подвел.


Далее пользователь удаленно делает перезагрузку, запускает приложение и остальные задания успешно выполняются.


Посему вопрос...что может быть ? Может "Спящий режим"  приводит к таким последствиям ???
Заранее спасибо !

> Посему вопрос...что может быть ?


Все што угодно: испортилась база, испортился винт, глючит железо, заглючил сервер, заглючило клиентское ПО, пользователь,.. и т.д.

> GanibalLector  (03.11.2008 13:46:00)  [0]

Информация об этом находится в логах.

2 Anatoly Podgoretsky ©   (03.11.08 14:05) [2]

firebird.log ???

Только мне эта инфа не о чем не говорит :(

> GanibalLector  (03.11.2008 14:50:04)  [4]

Я не знаю, какие логи ведет Firebird.
Касательно сообщения - попытка запуска, уже запущеного охранника.

> Если посмотреть на одну из таблиц, в которую происходит
> запись, то вижу следующее :<ID таблицы> 22123,22124,23009
> Т.е., насколько я понимаю, запись в таблицу БД была, но
> COMMIT подвел.

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

> Anatoly Podgoretsky ©   (03.11.08 15:24) [5]
> > GanibalLector  (03.11.2008 14:50:04)  [4]
>
> Я не знаю, какие логи ведет Firebird.

Практически никаких. Транзакционного лога там нет.


> GanibalLector ©   (03.11.08 13:46)  

Первым делом - проверка целостности БД, проверка, и еще раз проверка. Можно прогнать ее через Backup-Restore

2 Правильный$Вася   (03.11.08 15:36) [6]

>вот что-то я никак не могу из этого сделать твой вывод про коммит
что ты утаил?

А что не понятного ?
Например : insert into testtable values (gen_id(idtesttable,1),'test')
при каждом выполнении в табл. testtable будет новая строка и в поле Id будет "старое значение + 1 ".

Вот и у меня. Я получил данные с девайсов. Сохраняю их в БД.
Примерно так :



Когда случается потеря данных, то см [0]. Я про <ID таблицы> 22123,22124,23009. Если не случается, то все идет подряд.

2 DrPass ©   (03.11.08 15:36) [7]

>Первым делом - проверка целостности БД, проверка, и еще раз проверка. Можно прогнать ее через Backup-Restore

Backup-Restore делал. Эффект тот-же.

Проверка целостности...хм..не делал.
Ща почитаю как делается. Или намекните ;)

> выполнение первого ночного задания приводит к "зависанию"
> и потери данных.

зависанию компа или субд?
как проявляется?

> А что не понятного ?

да ты так написал, что я не врубился, что это значения одного поля, а не разных полей одной записи
да и не факт, что номера должны быть подряд
хотя логика тебе известнее, мож, у тебя дырок и не бывает
посмотри, стартована ли служба FB в момент, когда "зависает"

2 Правильный$Вася   (03.11.08 16:33) [10]

Пардон. Зависает мое приложение, которое сохраняет данные в БД.
Сам FireBird при этом работает. Т.е. это комплекс программ (все остальные проги для работы с этой же БД(правда они для просмотра данных) работают).

> Если посмотреть на одну из таблиц, в которую происходит
> запись, то вижу следующее :
> <ID таблицы> 22123,22124,23009
>
> Т.е., насколько я понимаю, запись в таблицу БД была, но
> COMMIT подвел.


Может COMMIT подвел. Может генератор каким-образом глюкнул, перескачив сотню значений. Что угодно.
У базы расширение не *.gdb надеюсь?

Спасение вижу только в логах. Как вариант: весь обмен с девайсами протоколировать в обычных текстовых (либо в системных) логах (включая ID-шник записи), а дальше долго и упорно в них разбираться (при этом пользу можно извлечь и по информации из стандартных системных логов).

>У базы расширение не *.gdb надеюсь?

Да

> GanibalLector ©   (03.11.08 17:16) [13]

Что "да"? GDB?

инет рвется :(
Да, у базы расширение gdb. FireBird 1.5

> Да


Опасно, если база и сервер под ХР. Файлы с расширением *.gdb регулярно резервируются, а при откате виндовс на точку восстановления ОС также восстановит и эти файлы.

2 Loginov Dmitry ©   (03.11.08 17:23) [16]

В моем случаи БД это промежуточное звено. Т.е. пользователь забирает информацию из базы в свою учетную программу(каждый день).

> GanibalLector ©   (03.11.08 17:27) [17]

Но "форточки" с таким расширением файлы копируют для восстановления системы.. потому при старте транзакции идет по любому запись в файл, на что и реагирует ОС копированием файла БД.. и если размер приличный, то... сам понимаешь..тормоза

Не вопрос...переделаю на fdb.
Но, ИМХО, проблема в другом.