Сегодня наткнулся на ошибку по удалению всех записей из регистра накопления, платформа 8.3.17.1549 x64, MSSQL 2019.

Пишу, чтобы были внимательны те, кто прочитает.
1. У регистра накопления №1 убираем признак "Разрешить разделение итогов".
2. Нажимаем обновление ИБ
3. Как начинает отсчитывать счетчик обработки записей нажимаем Ctrl + break.
4. Выставляем признак "Разрешить разделение итогов" обратно.
5. Переходим к общему реквизиту "ОбластьДанныхОсновныеДанные", в составе у регистра накопления №2 выставляем использование с "Не использовать" на "Автоматически".
6. Нажимаем обновление ИБ.
Профит, все записи которые в п.1 еще не успели обработаться - удалены безвозвратно.
Может это происходит на других объектах метаданных при разных ситуация (документы, справочники, регистры сведений, расчетов).

P.S: на багрепорте ошибку не нашел.

мьсе, кажется скучно...

(0) Продолжайте наблюдения.Еще во время обновления можно попробавть вырубить свет.Да и вообще что нибудь еще.

- Доктор, когда я вот вот так вот делаю у меня болит..((
- А вы вот вот так вот не делайте ))))

(2) В этом случае явно видишь что свет вырубился, а тут черный ящик который удаляет данные по своему смотрению.

(4) не по своему. до этого дойти надо и путь аж из 6 пунктов

Вот откуда у людей возникают такие мысли поизвращаться? Т.е. сам, значит, дождался работы системы, сам прервал процесс и материт разработчиков. Если взять пример, приведенный в (2), то если ТС подойдет и вырубит электричество, то виноваты электрики, что ли?

(6) На тестовой, ставлю эксперименты по структуре хранения данных.
Записей больше 50млн, надо оптимизировать хранение, запросы с учетом текущей бизнес-логики. При разработке было непонятно какие данные и в каком виде будут нужны.

(0) реструктуризация изначально была в транзакции - все ругались на нехватку памяти и длительному откату
сделали по другому (через копирование в фоне) - опять плохо...

Вам не угодишь....

а вообще просто посмотри на состав таблиц, все твои "пропажи" лежали в отдельной табличке и просто надо было запустить мастер експорта и все...

(8) Ну это всё-таки баг. Если 1с пытается эмулировать транзакции своими средствами с целью ускорения и облегчения - честь и хвала. Вот только данные терять не надо, отмена операции - штатная функция, это не срубание процесса 1с или зависание сервера...

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

Не трогайте дедушку, ему уже 120 лет, дедушка уже в глубоком маразме, у него весь мир говно и против него

(1) будет что вспомнить в старости

Все подобные нюансы решаются одним большим главным правилом, всегда стоящим первым пунктом:

"Сделайте архивную копию Вашей информационной базы — абсолютно необходимое требование перед действиями любого характера с конфигурацией"

(8) Не лежали. Смотрел в отчете штатном топ-таблиц в SSMS при повторном воссоздании ситуации. Просто вместо 50млн их стало 70тыс. Отдельная таблица сейчас не всегда создается, если можно текущую изменить (например, добавили реквизит).
(11), (12) :)
(10), (13) Я делаю, это тестовая для экспериментов и тоже с копиями. Базу рабочую никогда не убивал, только восстанавливал после манипуляций других разработчиков и консультантов.

(13) Это так то так, вот только критерий "база рассыпалась, поднимаем бэкап" в данном случае весьма неочевидный. И может выплыть после того как начнут работать и набивать данные.

(8) + (14) Понял, в новую таблицу 70тыс с префиксом NG успели записаться, потом при повторной реструктуризации все таблицы с NG переименовались в текущие, а старые - грохнулись.

(16) /то что же получается, дно пробили не 1С и не разработчики, а один немного поистеривший разработчик? :))

+(17) Это ...

(17) Почему это? Я просто написал как все удаляется (видимо, это относится и к документам, табличным частям и тд).

При первой реструктуризации "Таб1" (50млн), создается "Таб1NG" (70тыс).
Прерываем. Записи больше не обрабатываются, "Таб1NG" остается. Сеанс не выкидывает.
Обрабатываем второй регистр "Таб2", создается "Таб2NG".

Далее "Таб1" и "Таб2" удаляются, "Таб1NG" и "Таб2NG" переименовываются в исходное.
Хотя должно было "Таб1NG" и "Таб2" грохнуться, "Таб2NG" переименоваться в "Таб2".

(19) Притом после 1-ого прерывания можно закрыть 1С, покурить месяц, накатить обновление и ох**ть от увиденного :)

(20) То есть у тебя претензия, что 1С защиту не от всех дураков сделала или что?

(21) т. Е. ТС дурак потому что он воспользовался ШТАТНОЙ возможностью платформы. И чтобы не быть дураком он должен чаще стучать в бубен?

(22) С помощью ШТАТНОЙ возможности платформы можно винчестер отформатировать, например
Или написать письмо на fsb.ru о том, что в Кремле заложена бомба, тоже с помощью ШТАТНОЙ возможности платформы

(0) Сдуру можно и .. сломать. Простите, не удержался.

ТС совершенно прав. Если есть _штатная_ возможность прерывания процесса - то и поведение при этом должно быть совершенно штатным. То есть, транзакционным. Если убрали транзакционность - то и штатное прерывание надо убирать. Или оставлять базу после этого в четком "недореструктуризированном" состоянии, чтобы не было возможности продолжить действия без заверешния реструктуризации.
Да блин, даже в семерке это было! А тут..

(23) Для этого нужно рукоблудить. Т.е. писать код.
А тут ... без объявления войны

(8) Изначально - это в бета версии 8.0?
(26) Ага - "всего лишь" изменение настроек разделения...

(27) >Ага - "всего лишь" изменение настроек разделения...
Думаю, можно подобрать более простой пример.

Зачем разрешили Ctrl+Break, если это ведет к удалению данных

(29) Ловушка для дурака

(30) помощь эволюции

(0) ты изобрел частичный и, надеюсь, бстрый truncate

Реактор в Чернобыле практически так же взорвался.

(32) Да ладно, у коллег удалял базы со своего компа, никто же не настраивает права доступа в кластере и ведь не верят что так можно.

(25) в 1с есть механизм запуска продолжения прерванной реструктуризации, и по умолчанию он должен запускаться при повторной попытке запуска 1с.

То ли автор сумел этот механизм просто не заметить, то ли как-то обошел (возможно он пользовался не конфигуратором а чем-то другим).

лично я то же не в восторге от текущей методы реструктуризации, мягко сказать - он не идеален... но для 99% случаев он вполне сносный

(35) Сейчас при динамическом обновлении в ряде случаев предлагает завершить сеансы (при изменении модуля), два раза нажимаешь отмену (нет кнопки динамически), на третий раз она появляется.
Коллега в 8.3.13 смог добавить динамически рег.задание в метаданных и даже никого не выкинул.
P.S.: сторонними приблудами не пользуюсь.

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

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

Есть номер обращения в 1С по этому инциденту?

Тут мне по работе соообщили, что динамика рушит 8,3,17 серверные на скуле... Причём рушит с вероятностью >>50%

(0) ты в курсе, как 1с выполняет реструктуризацию? Она добавляет к таблицам объекта "old", создаёт такие же таблицы, но с учетом изменений в структуре. Затем из старых таблиц инсертит все записи в новую. Когда записи залились, удаляет старую. Возможно у тебя в базе висит таблица с именем "old"

(7) 50 млн записей это не много. С чего ты взял, что нужно что-то оптимизировать?

(39) брехня

(40) ага, только не old, а ng

И то, это зависит от версии

(37) ещё можно накатывать расширение, как альтернатива динамике.

Оно конечно не везде ещё работает, но зато где работает - там все чотко