Очищается регистр сведений #643017

Очень странная ситуация сложилась. Непонятно как чистится регистр сведений. С непонятной периодичностью, может раз день, может день простоять спокойно, может по несколько раз за полчаса. Чистка проходит максимум за 20 секунд на sql-ной базе размером в 22Гб. В регистре порядка 80 000 записей. Регистр подчинен владельцу. в модуле набора записей в процедуре ПриЗаписи стоит защита от записи с хотябы одним пустым измерением или владельцем. Голову уже сломали, что может быть и как с этим бороться.

Если в 1С совсем не докопаетесь, то поставьте профайлер SQL с отбором по таблице регистра и ловите запросы на удаление. Получите время когда удалили. Потом смотрите кто и что делал в это время по журналу регистрации.

Защита, надеюсь, отбор в наборе проверяет, а не сам набор?

чо за регистр и как там записи появляются? и к чему высказывание "Чистка проходит максимум за 20 секунд"? ты же чистить не хочешь, а наоборот сохранить

потому фото нет

Точно, раз узнали время (20 секунд), значит знают и момент, когда это происходит - значит причину легче найти.

Добавьте ещё защиту от записи пустого набора записей, а не только с пустыми измерениями или владельцем

Ищите код, вида:

значит по какому то событию чистится. Отладчик в помощь.

журнал регистрации в самой 1с чист, записи по изменению этого регистра одиночные. Время, когда очищается вычислили записью в лог количества записей в регистре. регистр контактной информации. 20 секунд, потому что интервал записи лога поставили 10 секунд, в течение 20 секунд количество постепенно уменьшилось до 0.

не пройдет, без отбора по владельцу записать не дает, и не дает записать с владельцем - пустой ссылкой

время знаете? смотрите ЖР, там будет видно Кто делал, потом паяльник в руки и допытывать - Что делал.

событие оставило бы хоть какие-то следы в журнале регистраций, а их нет!

Дает, судя по

Поверь мне.

на регистры событие "Данные: Изменение" только

А я что говорил (с)

без отбора не даст. Тем более, что поменять движения документа не дергаю сам документ - раз плюнуть.

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

Убирайте проверку на количество

кроме того, возможно И на ИЛИ поменяйте

да вообще всю проверку в топку :)

+100500 Что мешает заполнить значения отбора, но не установить использование?

Верьте

Конфигурация Рарус, небось?

может ведущее измерение.

Самое смешное, стояло все работало несколько лет, тут без изменения нами кода все начало сыпаться.

Кто-то чтото поправил, само не может

она самая

чудес не бывает. обновления были?

Не обязательно впрямую, но создались условия

обновления мы делаем раз в несколько лет и то накатом изменений вручную

Если КакоетоУсловиеКотороеНеВыполнялосьМногоЛетАСейчасНачалоВыполняться тогда

Когда имел дело с конфой от Раруса, мы практически сразу отказались от поддержки, т.к. пришлось практически полностью всю конфу перелопачивать. Там таких залепух на каждом шагу полно.

даже если бы такой код отработал, он бы выдал в журнале регистраций что-то подобное 07.12.2012 15:17:00    Администратор        Данные. Изменение    Зафиксирована    Регистр сведений. Контактная информация    komp            07.12.2012 15:16:59 (93144331)        1С:Предприятие    171

И даже если бы этот предательский код отработал, как бы он смог так быстро все зачистить? 80 000 записей меньше чем за 8-10 секунд, на нашем виснущем сервере

а этому коду время много не надо, это быстрый убийца регистров

Используй подписку на события для логирования этого события В две строчки кода ... зачистить за 10 сек и больше записей ... PS: У меня было такое ... дело оказалось в умелый руках программистов

если он только обойдет ПередЗаписью в модуле набора записей. а это вообще возможно?

А как тогда журнал регистрации?

это весь код в ?

Запусти у себя в базе эти две строчки : И насладись скоростью удаления ;)

вот сюда попадает, перед тем как Рег запишется

Легко: 1) Возможно у него не настроен журнал на эти события 2) Возможно удаляются эти строки в коде

Ну по идее, этому коду на удаление 80000 записей на виснущем сервере потребуется ~4 секунды

а вы недавно не увольняли программиста? Ну там без выходного пособия...

Очистил тебе регистр ?

Или админа ) Который на SQL сервере скрипт забацал

нет, все на месте и почти довольны

+ Сто процентов согласен !

Что то долго для сиквела таблица очищается...

Твои две строчки кода не попортят регистр, чтобы очистить регистр надо отборать всех контрагентов ~20000 и потом циклом прошпарить их всех записывая их КИ. И это нифига не ~4 секунды...

ну если только скрипт, потому что уже всю конфигурацию перевернули по словам "КонтактнаяИнформация"

о_О. Мсье знает толк в извращениях. Вашим методом регистр несколько минут будет очищаться.

Дак он так и может очистится только. Что бы очистить надо иметь ссылку контрагента которая подставится в Объект и прекрасно запишется(стерётся), Иначе никак. Другой вариант только в SQL...

+1

Фейспалм!!! А вы попробуйте сначала, прежде чем такие заявления делать .:)

Про черного 1сника уже было?

Подожди, еще время не пришло :)

Аж прям сердце кольнуло от твоего поста ...

Зачем Вы с очевидным спорите? Очищается регистр? Очищается. Зачем себе противоречить и говорить что этого не может быть? :) Ищите кривой код

см - все верно, очистить ни ума ни времени много не надо)

см . Оказывается надо и то и то :):):)

:) Вперед, с песней (и заготовленным вазелином), удаляй бэкап и запускай эти безвредные 2 строки на своей боевой

только не перепутай, сначала - удалить бэкап, потом запустить. Не наоборот

Да все варианты опробованы уже. Всё протестировано уже. =)

Точно все? Точно всё протестировано? МенеджерЗаписи тоже протестировал?

ну допустим эта проверка если например заполнен Тип, она и не сработает. И всё вычистит.

После этого идет проверка на Владельца (объект).

Менеджер не тестил.

Дядка, ну. Ну напрягись. Сколько раз эта проверка выполниться при пустом ЭтотОбъект?

А как может быть пустой "этотОбъект" если это в модуле "ПередЗаписью" регистра сведений?

пришло! пришло время! , давай про черного!

Ребят, я понимаю юмор дело хорошое, но давайте проникнимся всей полнотой трагизма данной ситуации! =) О как завернул)) Проникаемся.. А потом я с радостью прочитаю про вашего черного(безголового) 1сника (всадника)..))

Сделай сначала , потом вместе будем проникаться полнотой трагизма

+ в процессе заодно убедишься в

запись в регистр сведений идет в два этапа: 1. стираются старые записи; 2. пишутся новые. то есть ответ на ваш вопрос: при перезаписи пустой этот объект там будет всегда, в 100% случаев.

Бугога. Хотя чему я удивляюсь: одинэснег, который 1С не знает - это нынче норма.

появились новые подробности: регистр очистился когда в базе было только 3 пользователя, которых на работе в это время не было. И еще, не знаю, связано с этим или нет, но примерно в то же время, когда и стали происходить эти события, при записи контрагента(а может регистра контактной информации) стала вылетать ошибка: "Ошибка при выполнении обработчика {...}: Ошибка при выполнении метода контекста (Записать): Конфликт блокировок при выполнении транзакции; Microsot OLE DB Provider for SQL Server: Transaction..." к сожалению полный текст не сохранился

Регламентные задания возможно?

нет, все отключено и ни у кого кроме администратора нет к ним доступа

Ну, ВОЗМОЖНО эта ошибка говорит о том, что кто-то пытается записать контактную информацию в тот момент, когда она как раз удаляется. А возможно и нет.

а может из-за этой ошибки стереться регистр?

Ну, как вариант, в планировщике у кого то бомба заложена....

все это закрыто от простых пользователей

Нет, в этот момент он уже стирается.

Чудес не бывает.

Продолжение нашей эпопеи: Отправили cf-ник в Рарус, они поглядели, развели руками, предложили поставить ловушки в модуле набора записей. Поставили: результата 0, одни испуганные пользователи. Как будто очистка в этот модуль вообще не заходит.