Бесследное удаление документов из базы #573171

Дана штатная конфигурация ЗУПа (одна из последних версий - 35 вроде) на платформе 8.2. Вопрос к знатокам именно штатных конфигураций - есть ли какая-либо возможность у пользователей конфигурации удалить документы в базе без регистрации этого события? Ну даже если предположить, что этот человек умеет кодить на 1С но полными правами не обладает (зато обладает любыми другими из набора штатных прав). Или может в конфигурации есть такие механизмы? Я понимаю, что звучит глупо, но всё же хотелось бы уточнить (вдруг чего не знаю).

полные права это блеф достаточно стать администратором отключить журнал кокнуть включить обратно

Это же всё можно закодировать и выполнить в привилегированном модуле? Эффект будет именно такой как ты описал? Или эта фишка там не прокатит?

зато обладает любыми другими из набора штатных прав ещё раз нет в 1С полных прав это роль, а не право у твоего кодера ест право администрировать, которое живёт в корне конфы ?

можно не отключая журнал загрузить dt какой-то давности. В журнале будет только запись о заходе в конфигуратор.

угу, можно и так: выгрузить - кокнуть в копии - выгрузить копию - загрузить

Да, роли. Некорректно выразился. Вообще у моего кодера нет доступа в рабочую базу. Есть админ БД. У него роль "Полные права" с соответствующим правом администрирования (галочка в роли). Просто хочу понять - если бы человек захотел подкинуть бяку - как бы он это провернул на примере бесследного удаления документов. Возможно ли такое на уровне механизмов самой конфы или на уровне пользователя, а может сама конфа может дурить (какие-то обработки или ещё что-то)? Получилась некрасивая ситуация, когда пользователи утверждают, что они занесли документы в базу. А их там нет. И нет никаких следов в том же журнале регистрации. И restore на sql на рабочую базу никто не делал (логи sql изучали) и dt

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

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

+ 1 кстати настройка журнала в журнале отражается: Информационная база. Изменение параметров журнала регистрации

Нет события проведения. Нет номера и его даты. События удаления так же нет. Нумерация введётся вручную. И разрыв в десяток документов имеется. Вот это аргумент пользователей. Я вот чего подумал, если разработчик изменит привилегированный модуль и разместит процедуру удаления и отключения журнала регистрации там - эта методика сработает? Вот например, если пробовать обработкой удалять документы (самописной, через Объект.Удалить) то запись об этом в журнал регистрации вносится. У меня нет недоверия к разработчику, как впрочем и нет недоверия к пользователям, но просто хочется разобраться в ситуации - если это случилось то как это могло произойти. Может какой-то штатный механизм в конфе отработал?

журнал при загрузке базы очищается, насколько я помню

[Нет события проведения.Нет номера и его даты. ] тогда о чем базар ? не было ввода документов

2 неправильно помнишь.. с чего бы это он очищался вообще?

в 8.2 такого точно нет

Журнал транзакций, вроде очищается, а не регистраций.

Это само собой.

2 почему журнал транзакций очищается? во всех ли СУБД? при всех ли настройках журналирования?

Я не помню подробностей надо смотреть. Где-то это сообщение мне регулярно на глаза попадалось после загрузки dt. Типа "журнал транзакций будет очищен" или как-то так.

сейчас на MS SQL 2003 c full проверим

угу... это при том, что у пользователя, под которым сервер обращается к СУБД может вообще не быть на это прав...

овнером то юзер является

2 овнером? что такое овнер в ДБ2?

а что такое DB2 ?

ДБ2 это одна из четырех СУБД с которым работает 1С; и  вы предполагаете что 1С такая умная что будет знать механизмы работы с логом транзакций всех 4-х.

купился=) то,что 1С умет работать с диалектами DMO разных серверов - очевидно

Базы на MSSQL. Овнером является SA В серваке приложений база зарегистрирована под SA

2 это не имеет значения, на какой СУБД именно ваша БД. 2 да, это понятно.. Но вот реализация журналирования у всех сильно разная. Ну и вообще это противоречит парадигме. :)

терпи через две минуты RAM драйв смонтируется и будет получен ответ

2 ну, потому что может быть и по-другому.

2 пф... Знаете чем неврастеники отличаются от шизофреников? Неврастеники знают что 2*2=4, но каждый раз нервничают, что могут знать это неправильно... А шизофреники знают, что 2*2=5 и спокойны... :) я - спокоен. :)

продуктив фулл лог 3 Гб, база 4 Гб dt от пустой базы 2 Кб результат после загрузки - размер не измененный размер после шринка базы лог 3 Гб, база 7 Мб размер после транкэйта и шринка лог 0,5 Мб, база 3 Мб резюме лог не очищаетя на MS SQL 2003 дефолтных настройках

все зависит от прав к серверам вариант 1 1. скопировал файл лога 2. удалил 3. вернул файл лога вариант 2 1. скопировал таблицу пользователей 2. очистил ее и получил полный доступ вариант 3 на другом сервере 1с создал базу и подключил ее к твоей SQL базе, далее делай что хочешь лог будет на другом сервере вариант 4...10 их много могу придумать