Возможные ошибки и их исправление

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

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

Ошибки в структуре файлов
(нарушения физической целостности)

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

Программа Jinnee может проверять физическую целостность только TBL-файлов. Итак, что может происходить при проверке TBL-файлов. Каждый TBL-файл разбит на блоки фиксированной длины кратной 512 байт. При обнаружении ошибки в файле могут выдаваться сообщения - "Ошибка в блоке XXXX таблицы ‘ХХХХ’!", "Разрушен блок данных ХХХХ".

Ошибка в блоке может "задеть" какую-то конкретную запись. В этом случае будет выдан запрос - "Разрушена запись XXXX! Корректировать блок данных?". Если ответить "Да", программа сохраняет, по возможности, информацию из сбойного блока. Очень может быть, что после коррекции некоторые записи этого блока будут содержать случайные данные.

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

Почти всегда после сообщений подобного рода следует огромный список нарушений логической целостности базы данных, поэтому лучше восстановить резервную копию базы данных.

Ошибки в данных (нарушения логической целостности)

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

Рассмотрим теперь подробнее возможные неисправности и возможные действия по исправлению ошибки. В любом случае всегда есть кардинальное, но не оптимальное решение - удалить ошибочную запись. Удалять, как правило, имеет смысл, только если вся запись испорчена, или если в базе данных содержится две одинаковые записи. Итак, возможные ошибки:

Ошибка "Не найдена запись"

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

Рис. 6-19 – Фрагмент ошибки "Не найдена запись"

То есть в поле записан определенный адрес записи, а в связанной таблице такой записи нет.

Рис. 6-20 – Переход к связанной записи

В нашем примере это выглядит так: запись с адресом 00000001 из таблицы "Разовые н/у" ссылается на связанную запись из таблицы "Расчёты" с адресом 00000732. Если перейти по связи в "Расчёты", то будет выдано сообщение об отсутствии данной записи в таблице.

Рис. 6-21 – Предупреждение об ошибке

Исправить эту ошибку можно двумя путями - ввести в поле правильный адрес, если, конечно, известно верное значение. Или ввести "нулевую ссылку" - значение "нет".

Ошибка "Связь не один в один"

Эта ошибка возникает в связях типа "один к одному" или "условная связь".

Рис. 6-22 – Фрагмент ошибки "Связь не один в один"

Эти связи организованы так, что обе связанные записи ссылаются друг на друга. Если же запись A ссылается на запись B, а та в свою очередь ссылается не на А, как должна бы, а на C, то будет выдано сообщение "связь не один в один". Для устранения таких ошибок нужно разобраться, кто же на кого, в конце концов, должен указывать.

Рис. 6-23 – Просмотр ошибочных записей

Например, таблицы "Сотрудники" и "Сотрудники(расширение)" связаны между собой отношением "один к одному". В нашем примере эта связь нарушена: запись 00000000 из таблицы "Сотрудники" ссылается на запись 00000001 из таблицы "Сотрудники(расширение)". На эту же запись ссылается и запись 00000002 из таблицы "Сотрудники".

Рис. 6-24 – Переход к связанной записи

В свою очередь, запись 00000001 из таблицы "Сотрудники(расширение)" ссылается не на запись 00000000, а на запись 00000002 из таблицы "Сотрудники". Для исправления ситуации, необходимо либо удалить ошибочную запись 00000000, либо в поле связи указать значение "нет".

Это простейший и самый распространенный случай. Теоретически могут быть и более сложные вариации.

Начиная с версии 2.2, добавлена возможность объединения "двойников"  таблицы "Лица". У всех, кроме одной, дублирующихся записей по полю "Лицо_" требуется проставить значение "Нет",  далее эти записи отбираются пробелом и объединяются с записью, в которой значение поля "Лицо_" было оставлено.

Ошибка "Ссылается не на узел"

Ошибка может возникнуть в иерархии, если какая-то запись ссылается не на узел, а на лист иерархии.

Рис. 6-25 – Фрагмент ошибки "Ссылается не на узел"

Запись 00000008 ссылается на запись 00000005, которая, в свою очередь, является листом и лежит в корне таблицы. По определению на лист иерархии не должна ссылаться никакая запись.

Самое простое в такой ситуации - для всех записей, которые ссылаются на лист, поставить в поле иерархии значение "корень", при этом не надо изменять признак, обозначающий, является ли сама запись узлом или листом.

Рис. 6-26 – Вариант исправления ошибки

После такой операции все исправленные записи окажутся в корне соответствующего справочника СБиС++, и их можно будет переместить в нужное место стандартными операциями. Такое может не пройти для складской картотеки и для реестра документов, так как в корне этих таблиц могут находиться только специальные записи. Это уже специфика комплекса СБиС++. В этом случае нужно найти запись-узел и вместо ссылки на корень ввести ссылку на этот узел.

Ошибка "Неверный номер условной таблицы"

Ошибка, появляющаяся только в условной связи в записях общей таблицы.

Рис. 6-27 – Фрагмент ошибки "Неверный номер условной таблицы"

Напомним, что с одной стороны условной связи находится одна таблица, записи которой могут ссылаться на разные таблицы. В поле записи общей таблицы хранится название таблицы (определяемое по коду в словаре данных), на которую ссылается эта запись. Как видно из примера, запись 00000000 из таблицы "Лица" ссылается на таблицу "Номенклатура". При сбое  в программе может случиться так, что в этом поле будет указан код несуществующей таблицы. В нашем примере, запись 00000002 ссылается на несуществующую таблицу с кодом "А".

Исправить ошибочную ситуацию можно следующими способами:

•  наилучшим вариантом будет восстановить резервную копию БД;

•  либо указать в поле общей таблицы  название правильной таблицы, либо "нулевую ссылку" - значение "нет" (крайний вариант); в этом случае, советуем воспользоваться командой "Заполнить по шаблону" для редактирования сразу группы записей.

Ошибка "Неверные данные в поле"

Эта ошибка может возникнуть в поле любого типа, не только в поле связи. Означает она, что значение в этом поле не удовлетворяет внутренним ограничениям поля. Например, для полей типа "целое" проверяется, входит ли число в определенный диапазон (задается разработчиком приложения).

Чтобы исправить эту ошибку, нужно ввести корректное значение в ошибочное поле. Если же большинство полей записи содержат явно ошибочные данные, лучше просто удалить эту запись.

Ошибка "Неверные данные в большом двоичном поле"

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

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

Заключение

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

Если была выявлена ошибка, описание которой не рассматривалось в данном руководстве, то за подробным разъяснением дальнейших действий по устранению этой проблемы, можно обратиться к специалистам по телефонам "Горячей линии СБиС++".