Ошибка при проверке логической целостности. #84674

При проверке логической целостности вылетает такая ошибка. !! Проверка содержания справочников. Прайс_лист. Элемент. Для подчиненного элемента не удалось создать элемент в род. справочнике !!! Проверка содержания справочников.  Неисправимая ошибка. Вопрос такой, что это означает? (Прайс_лист подчинен справочнику "Владелец прайса") Как отловить элемент в справочнике "Прайс_лист" который вызывает эту ошибку?? Как вообще можно исправить эту ситуацию?

Up

При проверке или при проверке и исправлении?

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

глянь фоксом, в копии сортани по PARENTEXT - на 90% сразу увидишь пустой или кривой в нач. или кон списка.

Ты сам то понимаеш, что это и есть исправление логической целостности? Если нет, то готовь веревку, тебя ей за одно место подвесят...

Нашел 2 элемента с PARENTTEXT = 0 !! Один косяк, они совершенно пустые кроме поля ID и IDD (от МОДа) Щас попробую найти по IDD и грохнуть

будь осторожен, следи за собой

Сделаю так, помечу на удаление, сделаю КСЦ, если ссылок нет удалю. Так пойдет?

впиши какой-нить реальный PARENTTEXT Опасности: копия БД, кодовая страница, трамвай

наоборот фразы должны быть, по порядку :)

>Опасности: , кодовая страница, трамвай ?? В чем опасность? и что такое трамвай? (Я надеюсь что ты не имеешь в виду трамвай который по рельсам :-) )

Он самый :). Когда избегнешь первые две опасности, все сделаешь как надо, побежишь домой радостный не оглядываясь... а тут ... он ... трамвай ... левая ножка хрусь ... правая ножка хрусь ... берегись.

Я то понимаю, но пользователям не объяснишь почему вдруг у них все справочники перемешались. Вот за это меня бы точно повесили )). Поэтому приходится поддерживать базу в том виде в котором она есть. А учитывая что каждый год приходится базу переносить на следующий год. Порой тупым копированием справочников и переносом остатков и вз/расчетов. То такие косяки просто неизбежны. А делать это приходится из-за того что dbf > 2 Гигов не держит (((

Постараюсь не попасться )) Удалил, вроде ссылок не было (да и как они могли быть )) элементы полностью пустые были, фиг знает как они создались, но увидеть в конфе их никто бы не смог) Щас буду тестировать

+ Нуралиевы ваще кабаны, что выпустили версию 7.7. 7.5 давало такой задел работы по кивирянию в дбф. За что теперь платить продвинутым пацанам в одинэсэ?

Кто тебе сказал, что не держит?

Опыт, весьма горький. Попробуй поработать над востановлением базы которая весит больше 10 гигов. По времени это (((((((((. И вообще я не говорю за весь формат dbf а лишь за тот который использует 1С 7.7.

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

Не реально по срокам и потерям для организации. Потом ведь надо все проверить!!! Все будем выправлять когда будем переходить на 8ку.

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

Нереально проверить что данные корректны, в сжатые сроки

При чем тут восстановление... Базы больше двух гигов нормально живут и на дбф...

Во первых я говорил не про размер всей базы а про размер отдельного файла, в моем случае это файл движений регистра. Во вторых представь вот ты сохранил базу размером > 10 гигов. Делаешь обмен с переферийками и тут тебе "Хренова ошибка записи в файл. код такой то" ты поручишься что данные в базе у тебя корректны?! Я нет. Поэтому Восстановление + переиндексация такой базы это сколько времени??

Ура! Все закончилось успешно. Спасибо всем за дискуссию. Отдельное спасибо "Пролд" за помощь.