Вход | Регистрация
 
1С:Предприятие :: 1С:Предприятие 8 общая

удаление всех записей из регистра накопления при прерывании обновления ИБ по Ctrl-Break

удаление всех записей из регистра накопления при прерывании обновления ИБ по Ctrl-Break
Я
   timurhv
 
19.11.20 - 19:21
Сегодня наткнулся на ошибку по удалению всех записей из регистра накопления, платформа 8.3.17.1549 x64, MSSQL 2019.

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

P.S: на багрепорте ошибку не нашел.
   assasu
 
1 - 19.11.20 - 19:26
мьсе, кажется скучно...
   bolder
 
2 - 19.11.20 - 19:28
(0) Продолжайте наблюдения.Еще во время обновления можно попробавть вырубить свет.Да и вообще что нибудь еще.
   ДенисЧ
 
3 - 19.11.20 - 19:31
- Доктор, когда я вот вот так вот делаю у меня болит..((
- А вы вот вот так вот не делайте ))))
   timurhv
 
4 - 19.11.20 - 19:31
(2) В этом случае явно видишь что свет вырубился, а тут черный ящик который удаляет данные по своему смотрению.
   assasu
 
5 - 19.11.20 - 19:37
(4) не по своему. до этого дойти надо и путь аж из 6 пунктов
   Seducer
 
6 - 19.11.20 - 19:48
Вот откуда у людей возникают такие мысли поизвращаться? Т.е. сам, значит, дождался работы системы, сам прервал процесс и материт разработчиков. Если взять пример, приведенный в (2), то если ТС подойдет и вырубит электричество, то виноваты электрики, что ли?
   timurhv
 
7 - 19.11.20 - 20:05
(6) На тестовой, ставлю эксперименты по структуре хранения данных.
Записей больше 50млн, надо оптимизировать хранение, запросы с учетом текущей бизнес-логики. При разработке было непонятно какие данные и в каком виде будут нужны.
   vde69
 
8 - 19.11.20 - 20:20
(0) реструктуризация изначально была в транзакции - все ругались на нехватку памяти и длительному откату
сделали по другому (через копирование в фоне) - опять плохо...

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

а вообще просто посмотри на состав таблиц, все твои "пропажи" лежали в отдельной табличке и просто надо было запустить мастер експорта и все...
   Провинциальный 1сник
 
9 - 19.11.20 - 20:40
(8) Ну это всё-таки баг. Если 1с пытается эмулировать транзакции своими средствами с целью ускорения и облегчения - честь и хвала. Вот только данные терять не надо, отмена операции - штатная функция, это не срубание процесса 1с или зависание сервера...
   ReaLg
 
10 - 19.11.20 - 20:44
(0) Ну, как бы плохо... Наверное...
Но у меня уже очень-очень давно заведено правило ничего в конфе без бэкапа не менять. Если что-то пошло не так - сразу поднимать бэкап и делать заново. И не просыпаться ночью в холодном поту "а как оно там после отмены реструктуризации живет"...
   PR
 
11 - 19.11.20 - 20:45
Не трогайте дедушку, ему уже 120 лет, дедушка уже в глубоком маразме, у него весь мир говно и против него
   vi0
 
12 - 19.11.20 - 20:58
(1) будет что вспомнить в старости
   Dzenn
 
13 - 19.11.20 - 21:22
Все подобные нюансы решаются одним большим главным правилом, всегда стоящим первым пунктом:

"Сделайте архивную копию Вашей информационной базы — абсолютно необходимое требование перед действиями любого характера с конфигурацией"
   timurhv
 
14 - 19.11.20 - 21:26
(8) Не лежали. Смотрел в отчете штатном топ-таблиц в SSMS при повторном воссоздании ситуации. Просто вместо 50млн их стало 70тыс. Отдельная таблица сейчас не всегда создается, если можно текущую изменить (например, добавили реквизит).
(11), (12) :)
(10), (13) Я делаю, это тестовая для экспериментов и тоже с копиями. Базу рабочую никогда не убивал, только восстанавливал после манипуляций других разработчиков и консультантов.
   Провинциальный 1сник
 
15 - 19.11.20 - 21:28
(13) Это так то так, вот только критерий "база рассыпалась, поднимаем бэкап" в данном случае весьма неочевидный. И может выплыть после того как начнут работать и набивать данные.
   timurhv
 
16 - 19.11.20 - 23:01
(8) + (14) Понял, в новую таблицу 70тыс с префиксом NG успели записаться, потом при повторной реструктуризации все таблицы с NG переименовались в текущие, а старые - грохнулись.
   PR
 
17 - 20.11.20 - 00:34
(16) /то что же получается, дно пробили не 1С и не разработчики, а один немного поистеривший разработчик? :))
   PR
 
18 - 20.11.20 - 00:34
+(17) Это ...
   timurhv
 
19 - 20.11.20 - 01:09
(17) Почему это? Я просто написал как все удаляется (видимо, это относится и к документам, табличным частям и тд).

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

Далее "Таб1" и "Таб2" удаляются, "Таб1NG" и "Таб2NG" переименовываются в исходное.
Хотя должно было "Таб1NG" и "Таб2" грохнуться, "Таб2NG" переименоваться в "Таб2".
   timurhv
 
20 - 20.11.20 - 01:12
(19) Притом после 1-ого прерывания можно закрыть 1С, покурить месяц, накатить обновление и ох**ть от увиденного :)
   PR
 
21 - 20.11.20 - 01:22
(20) То есть у тебя претензия, что 1С защиту не от всех дураков сделала или что?
   Aleksey
 
22 - 20.11.20 - 02:01
(21) т. Е. ТС дурак потому что он воспользовался ШТАТНОЙ возможностью платформы. И чтобы не быть дураком он должен чаще стучать в бубен?
   PR
 
23 - 20.11.20 - 02:46
(22) С помощью ШТАТНОЙ возможности платформы можно винчестер отформатировать, например
Или написать письмо на fsb.ru о том, что в Кремле заложена бомба, тоже с помощью ШТАТНОЙ возможности платформы
   SleepyHead
 
24 - 20.11.20 - 04:26
(0) Сдуру можно и .. сломать. Простите, не удержался.
   Провинциальный 1сник
 
25 - 20.11.20 - 05:55
ТС совершенно прав. Если есть _штатная_ возможность прерывания процесса - то и поведение при этом должно быть совершенно штатным. То есть, транзакционным. Если убрали транзакционность - то и штатное прерывание надо убирать. Или оставлять базу после этого в четком "недореструктуризированном" состоянии, чтобы не было возможности продолжить действия без заверешния реструктуризации.
Да блин, даже в семерке это было! А тут..
   Aleksey
 
26 - 20.11.20 - 06:20
(23) Для этого нужно рукоблудить. Т.е. писать код.
А тут ... без объявления войны
   Answer42
 
27 - 20.11.20 - 07:50
(8) Изначально - это в бета версии 8.0?
(26) Ага - "всего лишь" изменение настроек разделения...
   timurhv
 
28 - 20.11.20 - 11:24
(27) >Ага - "всего лишь" изменение настроек разделения...
Думаю, можно подобрать более простой пример.
   Вафель
 
29 - 20.11.20 - 11:26
Зачем разрешили Ctrl+Break, если это ведет к удалению данных
   Волшебник
 
30 - 20.11.20 - 11:31
(29) Ловушка для дурака
 
 Рекламное место пустует
   vi0
 
31 - 20.11.20 - 13:53
(30) помощь эволюции
   mikecool
 
32 - 20.11.20 - 13:56
(0) ты изобрел частичный и, надеюсь, бстрый truncate
   Провинциальный 1сник
 
33 - 20.11.20 - 13:57
Реактор в Чернобыле практически так же взорвался.
   timurhv
 
34 - 20.11.20 - 23:17
(32) Да ладно, у коллег удалял базы со своего компа, никто же не настраивает права доступа в кластере и ведь не верят что так можно.
   vde69
 
35 - 20.11.20 - 23:28
(25) в 1с есть механизм запуска продолжения прерванной реструктуризации, и по умолчанию он должен запускаться при повторной попытке запуска 1с.

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

лично я то же не в восторге от текущей методы реструктуризации, мягко сказать - он не идеален... но для 99% случаев он вполне сносный
   timurhv
 
36 - 21.11.20 - 01:17
(35) Сейчас при динамическом обновлении в ряде случаев предлагает завершить сеансы (при изменении модуля), два раза нажимаешь отмену (нет кнопки динамически), на третий раз она появляется.
Коллега в 8.3.13 смог добавить динамически рег.задание в метаданных и даже никого не выкинул.
P.S.: сторонними приблудами не пользуюсь.
   vde69
 
37 - 21.11.20 - 10:41
(36) добавление рег задания не приводит к реструктуризации.
Вообще любое динамическое обновление сейчас не приводит к реструктуризации, хотя 1с планирует это изменить и допилить так, что вообще любое обновление можно будет накатывать динамически, уж не знаю хорошо это или плохо, но про такие планы читал...

Вообще динамическое обновление в любом случае зло и пользоваться им надо только для исправления багов мешающих текущей работе, для всех других изменений в любом случае надо всех выгонять, даже если динамическое обновление возможно.
   TormozIT
 
38 - 21.11.20 - 14:11
Есть номер обращения в 1С по этому инциденту?
   ДенисЧ
 
39 - 21.11.20 - 14:15
Тут мне по работе соообщили, что динамика рушит 8,3,17 серверные на скуле... Причём рушит с вероятностью >>50%
   Конструктор1С
 
40 - 21.11.20 - 15:36
(0) ты в курсе, как 1с выполняет реструктуризацию? Она добавляет к таблицам объекта "old", создаёт такие же таблицы, но с учетом изменений в структуре. Затем из старых таблиц инсертит все записи в новую. Когда записи залились, удаляет старую. Возможно у тебя в базе висит таблица с именем "old"
   Конструктор1С
 
41 - 21.11.20 - 15:38
(7) 50 млн записей это не много. С чего ты взял, что нужно что-то оптимизировать?
   Ёпрст
 
42 - 22.11.20 - 00:13
(39) брехня
   aka MIK
 
43 - 22.11.20 - 01:10
(40) ага, только не old, а ng

И то, это зависит от версии
   aka MIK
 
44 - 22.11.20 - 01:12
(37) ещё можно накатывать расширение, как альтернатива динамике.

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


Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.