Исключительная ситуация EComponentError

**Коньяк** Вт Авг 26, 2014 9:44

Здравствуйте. Smeta.RU 8.0.0.26, Windows 7. При попытке выйти в сборник через троеточие в обосновании расценки в смете выдает вот такую ошибку (как в прикреплении). Наложение патча не помогает, база не ремонтируется. Можно что-нибудь сделать?

Ваша реклама

Да есть, такой косячок.
На мой памяти вы третий (счастливый обладатель Windows 7).
У себя (да и в СС) воспроизвести такую ошибку не могем... Соответственно и разработчик говорит "А что мы с этим можем поделать?"
Вы сможете описать вашу последовательность действий, приведшую к возникновению данной ошибки?

**expert69** Вт Авг 26, 2014 10:10

на Win 8 такая же проблема очень часто возникает (тут явно не в винде дело), но опять же "не всегда", поэтому уловить точную последовательность действий, чтобы возникала ошибка с вероятностью 100% не удается...

**Коньяк** Вт Авг 26, 2014 10:58

Самое интересное, что на другом компе, где такой же Win 7, на этой же базе на 26 патче таких ошибок не возникает. А последовательности никакой нет. Обычным образом смета набирается, поправки назначаются, ресурсы меняются, разделы создаются и т. д. В базе несколько тысяч объектов, попробовали на 10-ти - одна и та же ошибка. Смущает меня еще, что база не ремонтируется.

**expert69** Вт Авг 26, 2014 12:02

Если база не ремонтируется есть смысл подумать о переносе всех объектов в новую базу

**Semenov** Вт Авг 26, 2014 12:09

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

Коньяк писал(а):А последовательности никакой нет. Обычным образом смета набирается, поправки назначаются, ресурсы меняются, разделы создаются

"обычным образом" у каждого по-своему, это не описание. Программисты смет не набирают, а если и набирают, то точно не так как сметчики. Если есть ТОЧНАЯ последовательность, приводящая к ошибке, опишите её как можно подробнее и точнее, а еще лучше - сделайте видео с момента запуска программы, если не хватает терпения описать словами. Любая мелочь может оказаться важной. Если ошибка проявляется не всегда, но очень часто, значит что-то делается не так, как у всех остальных...

**Semenov** Вт Авг 26, 2014 12:13

expert69 писал(а):Если база не ремонтируется есть смысл подумать о переносе всех объектов в новую базу

есть смысл поделиться логами проверки, ремонта (Программы мониторинга БД) и сервера (firebird.log), чтобы понять, пора ли бить тревогу, или можно жить с этим дальше

**Коньяк** Вт Авг 26, 2014 13:14

А, кстати, где в Win 7 логи эти хранятся?

**arbeiten** Вт Авг 26, 2014 15:00

Сообщение удалено по причине нарушения п.12 правил форума: "На форуме запрещается отправлять сообщения не по содержанию форума/темы."

**Semenov** Вт Авг 26, 2014 15:49

Коньяк писал(а):А, кстати, где в Win 7 логи эти хранятся?

логи проверки и ремонта Программы мониторинга видны в отдельном окне (меню - информация - лог), ведутся в процессе выполнения операции, если запущена клиентская часть программы, и могут быть скопированы в системный буфер обмена из этого окна ([Ctrl+A], [Ctrl+C]) и сохранены в файл, например, через стандартный блокнот. Файл лога сервера (firebird.log) располагается в папке установки firebird. Представляет интерес фрагмент файла, относящийся к периоду проверки БД, т.к. в это время сервер записывает в него информацию о найденных в базе ошибках.

**Коньяк** Ср Авг 27, 2014 10:17

Здравствуйте. Удалось воспроизвести эту ошибку. Semenov оказался прав, "когда окно сборника закрывается сразу после копирования содержимого ячейки, напр., обоснования, без выхода из ячейки", эта ошибка и появляется. Самое интересное в том, что мы потом проверили базу (ошибок не было), попытались отремонтировать ее (ремонт не удался - логи проверки, ремонта и firebird прилагаю), потом наложили 26 патч - и ошибка ушла. Теперь бы с ремонтом базы разобраться, а то, боюсь, скоро рухнет она....

**Semenov** Ср Авг 27, 2014 11:00

С базой ничего криминального, ошибки при ремонте связаны с наличием "лишних" записей, которых по идее быть не должно (замечено, что подобные записи появляются при использовании firebird 2.5.0, точно не ясно при каких обстоятельствах; при использовании 2.5.2 таких случаев не выявлено). После удаления этих "лишних" записей база становится "ремонтируемой", и резервные копии восстанавливаются нормально.

**Коньяк** Ср Авг 27, 2014 11:50

Стесняюсь спросить, а как удалять эти самые "лишние" записи (самое главное, как узнать, что они лишние)?

**Semenov** Ср Авг 27, 2014 16:08

Коньяк писал(а):Стесняюсь спросить, а как удалять эти самые "лишние" записи (самое главное, как узнать, что они лишние)?

если Вы не владеете языком SQL, то лучше не стоит...
в Вашем случае достаточно выполнить три запроса, с помощью IBExpert (можно скачать в инете) или isql (входит в состав firebird):

Код: Выделить всё: delete from A_S_RES_CENLVL where not exists (select * from A_S_RES where A_S_RES.ID=A_S_RES_CENLVL.ID); delete from A_SMETA_INDLVL where not exists (select * from A_SMETA where A_SMETA.ID=A_SMETA_INDLVL.ID); delete from A_SMETA_CENLVL where not exists (select * from A_SMETA where A_SMETA.ID=A_SMETA_CENLVL.ID);

и лишние записи будут удалены

З.Ы.: совершенно не будет лишним на всякий случай предварительно переименовать файл БД и скопировать его.