v7: Исчезают элементы справочника, в dbf появляются дубликаты #566578

Оболочка 7.70.025. ОС Windows Server 2003 R2 SP2, терминал-сервер. В разделенном режиме 15-20 пользователей, сеансы только терминальные. Конфигурация самодельная, основана на компоненте Оперативный учет. Вес базы около 600 М. Проблема: примерно раз в неделю пропадают элементы одного и того же справочника. В документах остаются ссылки «элемент не найден». Непосредственное удаление объектов в конфигурации запрещено. Контроль уникальности в справочнике включен. При «Тестировании и исправлении» на этапе проверки логической целостности вижу следующее: «Проверка уникальности внутреннего идентификатора в справочнике. Модели. Элемент229(FUSION FJL-1211). Вн. идентификатор   95. Исправить вручную Неразрешенная ссылка. Создан новый элемент. Справочник Модели. Код  2049» Решаю так. 1) Редактирую dbf со справочником: сортирую по ID, вижу дубль Элемента 229 по полям ID, CODE, DESCR. Вручную меняю их для этого дубля, присваивая заведомо уникальные ID и CODE. 2) Прибиваю индексы. 3) Захожу в базу и помечаю дубль элемента на удаление. Удаляю с контролем ссылок (ссылок на дубль не было ни разу). 4) Запускаю поиск ссылок на автоматически созданный элемент ФС-1. Убеждаюсь в том, что это и есть пропавший элемент справочника. Восстанавливаю значения его реквизитов, перенося их из архивной копии базы. Я полагаю, что причина сбоев в dbf – в «недоблокировке» таблиц при одновременном доступе пользователей. В конфигурации много пакетных обработок и процедур импорта внешних данных, часто обращающихся к этому справочнику. Они используются в разделенном режиме, так как связаны не с проведением документов, а лишь с их записью. Раньше эта база работала на менее производительном сервере под Win 2000 Server. Проблема проявлялась примерно раз в два-три дня. Перед новым годом провели свертку базы (объем данных уменьшился примерно на 30%) и перенесли ее на современный сервер. Сейчас проблема проявляется в среднем раз в 10 дней. Прошу совета, что это может быть, и как это можно попытаться подлечить при помощи кода.

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

Вот тут проблема: >>В конфигурации много пакетных обработок и процедур импорта внешних данных, часто обращающихся к этому справочнику.

Ищи по всей конфигурации по ".Удалить"..

прямые запросы используются?

+100500

То есть это не бага, а фича? И где компромисс? Нет Удалить, тем более для справочников. А если б даже было, с чего бы ему вызывать затирание строк в таблицах?.. Нет, прямых запросов к таблицам нет. Все запросы - исключительно на языке запросов 1С. Забыла сказать: используется ВК Formex. Отсюда не может быть наводок?

Если проблема в файловой системе, то иногда помогает копирование файлов в другой каталог.

"А если б даже было, с чего бы ему вызывать затирание строк в таблицах?" Каких строк? Удаляются записи в справочнике -> возникают висячие ссылки в других объектах. ТиИ вместо висячих ссылок создает "заглушки" с теми же идентификаторами, что и в повисших ссылках.

Ну если в базе всё корректно - то можно предположить диверсию :)

не помог даже перенос базы на другой сервер..) "ТиИ вместо висячих ссылок создает "заглушки" с теми же идентификаторами, что и в повисших ссылках". Вот тут я недопонимаю: она создает дубликаты с теми же ID, что у нормальных (не исчезнувших) элементов, и записывает их на место пропавших. Кроме того, она создает ФС с уникальными идентификаторами для "пропаших" элементов. Второе, как я понимаю, нормально. А первое? Это и есть "заглушки"?

"Недоблокировка" это хорошо. Спросить то чего хотел? Может обработки посмотреть, хотя тут все и так наизусть знают. Главное, что типовая.

Хотела спросить у опытных людей 1) что это может быть и 2) можно ли с этим бороться кодом. Конфигурация не типовая ни разу, то есть косяки вполне могут иметь место. Только я пока не представляю, где копать.

Хароший вопрос. Пригласите специалиста.

С каким кодом? ДНК? Вопрос задай.

"Второе" и "первое" в данном случае - одно и то же блюдо. Заглушки это и есть ФС-ххх.

я не против пригласить специалиста, поскольку сама скорее бухгалтер, чем разработчик. если есть конкретные предложения - велкам в почту/аську. переформулирую вопрос: "что может вызывать дублирование элементов справочника путем создания неуникальных идентификаторов и запись их на место других элементов, приводящее к исчезновению последних?" не совсем, как мне кажется. У "заглушек", которые ФС, идентификаторы как раз уникальны. А вот откуда берутся дубли ID нормальных, существующих элементов?

Мадам не путет ID и код элемента?

не путает. ID и CODE - разные поля dbf. характерно то, что у дубликатов оба этих поля совпадают.

имхо, здесь затык "В конфигурации много пакетных обработок и процедур импорта внешних данных, часто обращающихся к этому справочнику"

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

Только прямое обращение. Ищи ADDB, т.к. XBase хватает монопольно.

ADDB читать как ADODB

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

Что это было?

Скорее всего стоит какая-то приблуда, которая снимает лок с ДБФ-ки при изменении

Еще один?

видишь ли, если всё делать штатно, то дубли ID не появятся никак. Ну скажи свою версию

Я сказал.

чё курим?

где?

поскольку вариант с железом отброшен, остаётся два основных варианта: 1. Удалить 2. прямой доступ к dbf-файлам базы нештатными средствами сделай поиск .Удалить и  .dll .exe по всему коду (конфа + внешние обработки)

в

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

ты поиск делала? а по внешним обработкам?

Точно барабашки...

А нет ли у клиентов смеси локальных/сетевых путей? Т.е., у некоторых путь локальный, а у других - сетевой.

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

и чё?

1. большой там код? если в скрин помещается, выкладывай

Не то ищешь.

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

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

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

Неуникальные ID получаются, если элемент справочника создан, но в таблицу счётчика (1SUIDCTL) уникального ID не успели записать значение - в итоге получается, что ID достаётся следующему элементу. Но в этом случае проблем с ссылками на элементы не будет, так как все ссылки на первый элемент автоматом будут указывать на второй, который затёр первый. Потеря ссылок может происходить, если элемент удалился или был кем-то удалён, а его ID никому не достался. Второй причиной может быть нарушение индексов, когда в DBF-файле элемент есть, но в CDX-файле он в индексе пропущен. Нужно просто попробовать после пропадания сделать переиндексацию и посмотреть, что получится. Также кривые ссылки делаются штатно через ЗначениеИзСтрокиВнутр, когда в эту функцию передаётся внутренний индетификатор несуществующего элемента - если потом такое "значение" присвоить полю другого элемента, то получаем несуществующую ссылку. P.S. ещё стоит посмотреть в сторону "автономные файлы" если работаете по сети - при их включении для 1С "умная" система скачивает на клиента dbf-файл целиком, а потом возвращает его на сервер только после закрытия, то есть завершения сеанса 1С (видел как это "работает" только один раз - проверять, к чему приведёт - времени не было, но сразу было ясно, что база - не жилец).

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

точно у всех юзверей используется один и тот же релиз? на всякий случай (до кучи) поставь 27-й, лишним не будет

Все работают в терминальных сеансах, на клиентских компах 1С вообще нет. На сервере стоит только один релиз - 25-й. А в 27-м есть какие-то исправления, касающиеся блокировки таблиц?

заявлено не было, поэтому и говорю "до кучи"