Неочевидный баг Истории данных, убивающий rphost

08.11.23

База данных - Администрирование СУБД

Расследование о том, почему команда ИсторияДанных.ОбновитьИсторию() убивала rphost.

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

В итоге начали глушить регламентные задания и нашли причину. Накануне трагедии была добавлена внешняя обработка с регламентными заданиями, и одно из этих заданий запускало создание версий для «Истории данных»

Код задания:

ИсторияДанных.ОбновитьИсторию();

 

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

Для начала была создана обработка с одной единственной кнопкой, выполняющей код, написанный выше. При запуске вручную выпадала ошибка:

 

 

 

Текст ошибки:

«На сервере 1С:Предприятия произошла неисправимая ошибка. Приложение будет закрыто»

Дальше стало интереснее. Коллега решил проверить, рушится на всех объектах или на каком-то определенном. История у нас в базе, в которой это происходило, велась только по документам.

Он написал небольшой цикл, в котором оббегал Метаданные.Документы и добавлял в массив документы, запуская обновление истории данных по выбранным типам документов.

Синтаксис:

ОбновитьИсторию(<ВключитьМетаданные>, <ИсключитьМетаданные>, <ВыполнитьОбработкуПослеЗаписиВерсий>, <АвтоУдалениеИзОбработкиПослеЗаписиВерсий>)

Таким образом был выявлен один из типов документов, на котором происходило «Крушение». Это основной документ для той конфигурации, в которой запускался регламент.

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

И все бы ничего, но именно по данному документу и еще по одному История данных была включена в самой конфигурации более полугода назад, мало того, по данному документу было включено «Обновление истории данных сразу после записи».

 

 

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

Дальше за проблему взялся я и полез в SQL. Я решил пройтись по таблицам Истории данных и посмотреть на «странности, которые бросятся в глаза»

Первым делом нужно было определить [_MetadataId] у документа, который приводит к катастрофе, сделать это было легко. Документ у меня был включен в конфигураторе, значит, мне его нужно было выключить программно и посмотреть в таблице [_DataHistorySettings] на [_MetadataId] у новой строки. Для программного отключения я использовал свою обработку Настройка состава "Истории данных"

Дальше я полез в таблицу [_DataHistoryMetadata], если кратко, в данной таблице хранится структура объекта, и при изменении в конфигураторе данного объекта создается новая запись с новым значением версии метаданных.

 

 

Хм… А почему у некого поля _Fld312 значение NULL по данному документу? Ранее я уже видел поля _Fldxxx в данной таблице, но в других конфигурациях, и стал догадываться, что это общий реквизит.

Далее я запустил первую попавшуюся под руку обработку по получению соответствия метаданных с наименованием в СУБД и вуаля.

 

 

Fld312 -> ОбщийРеквизит.ОбластьДанныхОсновныеДанные

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

 

 

Как будем лечить?

Вариант 1. Тушить пожар.

В обновлении истории подать исключенные метаданные.

Синтаксис:

ОбновитьИсторию(<ВключитьМетаданные>, <ИсключитьМетаданные>, <ВыполнитьОбработкуПослеЗаписиВерсий>, <АвтоУдалениеИзОбработкиПослеЗаписиВерсий>)

Вариант 2. Лечить проблему вопреки лозунгам фирмы 1С не лазить в SQL.

Я выбрал этот вариант.

Скрипт SQL:

 

update [Моя_БД].[dbo].[_DataHistoryMetadata] set _Fld312 = 0 where _Fld312 is NULL

 

Итог:

 

 

После этого регламент стал работать отлично.

Ошибка была отправлена в 1С.

 

Выводы:

1) Судя по всему, в фирме 1С не предусмотрели взаимодействие с общими реквизитами, в связи с чем если вы вдруг для каких-то «странных целей» добавите общие реквизиты, не забудьте прописать значение по умолчанию в SQL, иначе словите убийственный баг.

2) Не слушайте вендора, призывающего не лазить в SQL.

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

 

Полезные статьи по данной теме:

Версионирование объектов VS История данных

Настройка состава "Истории данных"

История данных. Изменения в платформе 8.3.24

ИсторияДанных rphost Баг ОбновитьИсторию Метаданные DataHistorySettings DataHistoryMetadata MetadataId общие реквизиты

См. также

Администрирование СУБД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ и решение ошибок СУБД. Во время реиндексации базы Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Не удалось найти объект "ИмяБазы.dbo._RefSInf21806", так как он не существует, или отсутствуют разрешения. Во время проверки целостности Ошибка СУБД: Microsoft SQL Server Native Client 11.0: Недопустимое имя объекта "dbo._RefSInf21806".

19.09.2024    2854    Xershi    8    

15

HighLoad оптимизация Администрирование СУБД Архивирование (backup) Системный администратор Программист Платформа 1С v8.3 Бесплатно (free)

Бэкап в Postgres состоит из набора граблей, которые нужно обойти для успешного восстановления. Они заложены в самых неожиданных местах от предмета резервного копирования (база или кластер) до структуры каталогов. Один неверный шаг и восстановление будет невозможным. Почему нельзя было сделать проще, как в MS SQL или Oracle? Почему бэкап в Postgres оставляет впечатление чьей-то лабораторной работы? Статья адресована прежде всего специалистам 1С, избалованным комфортом в MS SQL, в суровых буднях импортозамещения на Postgres.

13.08.2024    2533    1CUnlimited    9    

4

Администрирование СУБД Программист Платформа 1С v8.3 Конфигурации 1cv8 Россия Бесплатно (free)

В статье описала свой опыт аудита 1С базы, порядок действий + статьи, которые сильно помогли в работе.

14.07.2024    7632    limonen    16    

19

Администрирование СУБД Платформа 1С v8.3 Россия Бесплатно (free)

Безопасное полное удаление пользователей из конфигураций 1С.

25.06.2024    1515    It-digit    7    

2

Администрирование СУБД Системный администратор Платформа 1С v8.3 Бесплатно (free)

Ситуация: при обновлении серверной базы данных произошёл сбой и теперь невозможно войти ни в конфигуратор, ни в 1С:Предприятие по причине ошибки, вынесенной в заголовок. Рецепт лечения.

24.05.2024    2857    Kernelbug    9    

20
Отзывы
3. dsdred 3531 08.11.23 11:24 Сейчас в теме
(2) Добрый день.
Тех журнал снимали, но ничего там не увидели.
12:30.527006-0,EXCPCNTX,0,ClientComputerName=,ServerComputerName=,UserName=,ConnectString=
12:30.527007-59502998,EXCPCNTX,1,SrcName=CONN,process=1cv8c,OSThread=14668,ClientID=8,Txt=Outgoing connection closed
12:30.527008-0,EXCP,1,process=1cv8c,OSThread=14668,Exception=81029657-3fe6-4cd6-80c0-36de78fe6657,Descr='src\rtrsrvc\src\RemoteInterfaceImpl.cpp(850):
81029657-3fe6-4cd6-80c0-36de78fe6657: server_addr=ххххх descr=10054(0x00002746): Удаленный хост принудительно разорвал существующее подключение. line=1610 file=src\rtrsrvc\src\DataExchangeTcpClientImpl.cpp'
12:30.980002-0,EXCP,2,process=1cv8c,OSThread=3680,Exception=e0417abc-63b4-461b-b1b6-01d2d2b0cca5,Descr='src\mngui\src\ExceptionWriterUIImpl.cpp(717), shown to the user:
e0417abc-63b4-461b-b1b6-01d2d2b0cca5: На сервере 1С:Предприятия произошла неисправимая ошибка. Приложение будет закрыто'


Информацию об ошибке отправил сегодня с утра.
Присвоенный номер ошибки HL-747523
Ссылка: https://regevent.1c.ru/sbo/tp/e5ad52bc-7df8-11ee-8161-0050569f2415/info/
METAL; Mikhail-Kobtsev; +2 Ответить
Остальные комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. &rew 50 08.11.23 10:48 Сейчас в теме
Спасибо Вам, добрый человек! С этой историей данных одни проблемы. У меня, в частности, в расширении.
4. dsdred 3531 08.11.23 11:27 Сейчас в теме
(1)Не за что.
Расскажите какие у вас проблемы случались с Историей данных.
5. &rew 50 08.11.23 13:50 Сейчас в теме
(4) В схеме базы данных нет таблицы с именем DataHistorySettingsExt. Смысл был в том, что добавили в расширении свой регистр сведений, и при попытки его открыть в режиме предприятия, выдавал ошибку. Было на 8.3.22 платформе, грешил на нее. Обновил на 23, не помогло, пришлось впилить в конфигурацию пока.
31. crazycat 222 21.11.23 19:27 Сейчас в теме
(5) Удалось решить проблему? Столкнулся с точно такой же ошибкой после добавления нового расширения, при открытии любого объекта из нового расширения вылетает такая ошибка.

Здесь https://roscluster.ru/wp-content/themes/c300/files/podkluchenie_modulya.pdf есть упоминание этой же ошибки: "Если конфигурация работает под платформой 8.3.21 и в конфигурации есть расширения, установленные до перехода на платформу 8.3.21, то может оказаться что установка рассматриваемого модуля расширения при попытке запуска после установки может дать
ошибку SDBL:\nВ схеме базы данных нет таблицы с именем DataHistorySettingsExt. В этом случае следует добавлять расширение под версией платформы 1с 8.3.20."

В моем случае базу открыть в версии 8.3.20 не представляется возможным, конфигуратор просит версию не ниже 8.3.21.
38. &rew 50 22.11.23 06:38 Сейчас в теме
(31)Пока нет. В конфигурацию "впилил" свой регистр, а запись в него через подписку и тоже свой модуль. Грешу еще на режим совместимости УТ (11.4, которую по доброму обновить нужно), но пока руки не дошли.
39. crazycat 222 22.11.23 06:46 Сейчас в теме
(38) У меня получилось решить проблему. Ниже писал как. Попробуйте добавить справочник в расширение, включить у него Историю изменения данных, обновить конфигурацию, должна добавиться таблица DataHistorySettingsExt, после этого можно справочник сносить и добавлять регистр сведений
aleksey2; dsdred; &rew; +3 Ответить
40. &rew 50 22.11.23 07:23 Сейчас в теме
(39) Да, я видел Ваше сообщение. Пробовал. Мне не помогло. У меня регистр сведений. При создании галка стояла. Снимал - сохранял - ставил обратно. Запускал Обновление, чтобы идентификаторы обновить. Порожняк. Но идея понятна.
41. crazycat 222 22.11.23 07:25 Сейчас в теме
(40) В том то и фишка, что сначала нужно добавить именно справочник, потом его можно удалить, а потом уже добавлять РС.
42. &rew 50 22.11.23 07:26 Сейчас в теме
(40)А нет, похоже на Ваше сообщение было. Но что-то такое пробовал. Режим совместимости расширения не менял.
2. Mikhail-Kobtsev 08.11.23 11:15 Сейчас в теме
есть несколько вопросов:

- что происходило при "убийственной ошибки" в технологическом журнале?

- отправляли ли вы информацию об ошибке вендору? можете скинуть номер ошибки с bugboard 1C ?
EvgeniyOlxovskiy; METAL; +2 Ответить
3. dsdred 3531 08.11.23 11:24 Сейчас в теме
(2) Добрый день.
Тех журнал снимали, но ничего там не увидели.
12:30.527006-0,EXCPCNTX,0,ClientComputerName=,ServerComputerName=,UserName=,ConnectString=
12:30.527007-59502998,EXCPCNTX,1,SrcName=CONN,process=1cv8c,OSThread=14668,ClientID=8,Txt=Outgoing connection closed
12:30.527008-0,EXCP,1,process=1cv8c,OSThread=14668,Exception=81029657-3fe6-4cd6-80c0-36de78fe6657,Descr='src\rtrsrvc\src\RemoteInterfaceImpl.cpp(850):
81029657-3fe6-4cd6-80c0-36de78fe6657: server_addr=ххххх descr=10054(0x00002746): Удаленный хост принудительно разорвал существующее подключение. line=1610 file=src\rtrsrvc\src\DataExchangeTcpClientImpl.cpp'
12:30.980002-0,EXCP,2,process=1cv8c,OSThread=3680,Exception=e0417abc-63b4-461b-b1b6-01d2d2b0cca5,Descr='src\mngui\src\ExceptionWriterUIImpl.cpp(717), shown to the user:
e0417abc-63b4-461b-b1b6-01d2d2b0cca5: На сервере 1С:Предприятия произошла неисправимая ошибка. Приложение будет закрыто'


Информацию об ошибке отправил сегодня с утра.
Присвоенный номер ошибки HL-747523
Ссылка: https://regevent.1c.ru/sbo/tp/e5ad52bc-7df8-11ee-8161-0050569f2415/info/
METAL; Mikhail-Kobtsev; +2 Ответить
6. starik-2005 3080 08.11.23 14:39 Сейчас в теме
Не слушайте вендора, призывающего не лазить в SQL.
Ну вендор этот идиотский пункт не где-то там в рекомендациях прописал, а в лицензионном соглашении. Т.е. если ты пользуешься продуктом, то 1С выдвигает требование не лазить в базу посредством прямых запросов к СУБД. Не знаю, есть ли теперь там формулировка "на свой страх и риск", но информация о том, что 1С не несет никакой ответственности за работоспособность базы, в которую. лазили шаловливыми рученками, есть.
С другой стороны, как показывает многочисленная практика, 1С не несет никакой ответственности и в случае, если Вы в базу не лазите. Вот, например, с историей. Добавили общий реквизит - все сломалось. Понесла 1С ответственность за Ваш простой? Нет. Можно ли ей что предъявить? Что-то сомневаюсь.
Brawler; vakham; unknown181538; shiaju; METAL; NeLenin; dsdred; +7 Ответить
8. dsdred 3531 08.11.23 14:45 Сейчас в теме
(6)Чаще всего работа с 1с это принцип
Спасение утопающего - дело рук самого утопающего
Дмитрий74Чел; vakham; +2 Ответить
7. dsdred 3531 08.11.23 14:43 Сейчас в теме
(5)странный баг. У нас на 8.22 и 8.23 есть эта таблица. Как вариант можно её скриптами самолично создать. Но вообще странно.
9. kser87 2463 08.11.23 14:57 Сейчас в теме
А зачем вообще эта история данных?
10. starik-2005 3080 08.11.23 15:02 Сейчас в теме
(9)
А зачем вообще эта история данных?
Хранит изменения, чтобы было на кого пальцем показать в случае разборов. Раньше это были версии объектов, потом большинство внедрили себе какие-то подсистемы хранилищ, теперь вот 1С в коробке историю реализовала.
METAL; dsdred; +2 Ответить
11. dsdred 3531 08.11.23 15:20 Сейчас в теме
(9)Например для создания Событийных интеграций и ухода от планов обмена.
Так же для того чтобы уйти с БСПшного Версионирования объектов -> Версионирование объектов VS История данных
EvgeniyOlxovskiy; +1 Ответить
12. SerVer1C 794 08.11.23 16:17 Сейчас в теме
Не слушайте вендора, призывающего не лазить в SQL.

Поставил "+" за революционные идеи.
14. dsdred 3531 08.11.23 17:55 Сейчас в теме
(12) дело не в революцонности, а в туннельности мышления.

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

60-70% в sql не лезут.
Andreynikus; Jimbo; +2 Ответить
16. starik-2005 3080 08.11.23 21:41 Сейчас в теме
(14)
что делать если срочно нужно почистить данные в регистре сведений с несколькими миллионами записей?
А какие проблемы?
РегистрыСведений.МойРегистр.СоздатьНаборЗаписей().Записать();
18. dsdred 3531 08.11.23 21:54 Сейчас в теме
(16) проблем ни каких, кроме времени выполнения.
20. starik-2005 3080 09.11.23 10:34 Сейчас в теме
(18)
кроме времени выполнения
И на сколько дольше работает запись пустого набора относительно транкейта? А таблицу изменений не забудет скульшик почистить? Ну или зарегить там удаления объектов, чтобы оно уехало в другие базы, о которых скульщик ничего не знает или забыл (ну или ему никто не рассказал, что достаточно часто случается)?

ЗЫ: А вообще, скуль, ежу понятно, быстрее работает. Но если регистр сведений независимый, у него нет таблицы изменений, он никуда не ездит и ни с чем не синхронизируется, то особой разницы по времени между транкейтом и записью пустого набора нет. Да, скуль будет писать все удаленные записи в лог, но лог пишется достаточно быстро. И тут в каждом конкретном случае надо думать, как стоит делать.
Brawler; EvgeniyOlxovskiy; +2 Ответить
21. dsdred 3531 09.11.23 11:42 Сейчас в теме
(20) Если я делаю что-то в SQL, значит я уже обо всех последствиях подумал.
Первоначально спорные вещи сделаю на тестовой базе.

На практике было много вещей которые можно было сделать только на SQL в отведенные временные рамки.

П.С. Со мной как-то работал коллега которому давали ночь на переход с бухии 2 на бухию 3. При этом бухия 2 была сильно перепилена, в ней было очень много НСИ, документов и когда он переходил стандартными средствами укладывался минимум в 2 дня. Он несколько месяцев потратил чтобы нарисовать скрипты повторяющие то что делает 1с при переходе, вплоть до создания НСИ, документов и идентификаторов.
Потом он запустил этот скрипт и уложился в 1-2 часа.
Я до сих пор поражаюсь той работе которую он проделал.
Такие кейсы на Infostart'e не покажут.
EGOLEGE; tolyan_ekb; +2 Ответить
22. starik-2005 3080 09.11.23 13:21 Сейчас в теме
(21)
Он несколько месяцев потратил чтобы нарисовать скрипты повторяющие то что делает 1с при переходе, вплоть до создания НСИ, документов и идентификаторов.
Я знаю людей, которые на конвертации годы тратили, чтобы сделать функционально достаточный обмен (БП -> ЕРП, например).

У "нас" в одной конторе (три работы назад) был ежегодный переезд с усекновениемглавыиоаннабогослова выпилом из базы предыдущих периодов. В итоге сделали сначала скрипт на скуле, который чистил таблицы со старыми данными по границу периода, потом загружали обменом остатки на начало по взаиморасчетам (торговали услугами, поэтому товарных остатков не было). Потом коллеги сделали переезд в апреле, просто очищая все по конец 4-го квартала прошлого года, а к апрелю изменения того периода сводились на нет. Стало гораздо проще жить. А ведь чисто ТРИЗовское решение - разнесение во времени.
vakham; dsdred; +2 Ответить
29. Brawler 458 20.11.23 20:40 Сейчас в теме
(22) И получали по 100500 архивный баз каждый год?
23. reset2 17 09.11.23 17:38 Сейчас в теме
(14)
60-70% в sql не лезут.

и лучше пусть не лезут
24. dsdred 3531 09.11.23 18:03 Сейчас в теме
(23)пусть хоть одним глазком посмотрят для общего развития.
17. starik-2005 3080 08.11.23 21:44 Сейчас в теме
(12)
революционные идеи
Я когда-то такие "революционные идеи" нес в массы, но народ в комментах возбуждался совсем в другую сторону.
5. BabySG 22.06.15 08:27
(0) Статья крайне опасна (особенно для начинающих), т.к.:
1. Подобное использование нарушает ЛС
2. Полностью не учитывается, что в событиях объекта может производится дополнительная обработка при постановке/снятии пометки удаления
Проще говоря: чревато разрушением данных
13. human_new 691 08.11.23 17:16 Сейчас в теме
А обычное тестирование и исправление разве не помогало исправить эту ошибку?
15. dsdred 3531 08.11.23 17:59 Сейчас в теме
(13) непоможет. Да и скажите вы при каждой непонятной ситуации запускаете тестирование и исправление?

По большому счету с помощью этого бага можно положить любые сервера. И он не информативен.
19. Xershi 1545 08.11.23 22:09 Сейчас в теме
(13) похоже отсутствие значения по умолчанию эту проблему не решало.
25. reset2 17 09.11.23 18:07 Сейчас в теме
Накину, не с претензией, а дискуссии ради ;).

Возможно причина "бага" в п.2 из выводов? При обмене для ускорения реструктуризации не применялись методы подобные этому? =>
(Яндексим "Метод быстрой реструктуризации больших таблиц (10 миллионов записей и более) через SQL Server Managment Studio").
26. dsdred 3531 09.11.23 19:02 Сейчас в теме
(25)
Возможно причина "бага" в п.2 из выводов?

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

В принципе этот баг легко повторить. Я думаю даже с расширением можно повторить, а значит можно уронить облака 1с например.
30. Brawler 458 20.11.23 20:43 Сейчас в теме
(26) Небо падает!!!!
Прикрепленные файлы:
27. ilkaev_log2021 10.11.23 10:37 Сейчас в теме
(11) С платформенной историей неудобство в том, что сложнее достать таблицу версий и задействовать ее в запросах.
С БСП шной реализацией все т.к. данные лежат в РС.
28. dsdred 3531 10.11.23 11:03 Сейчас в теме
(27) Это спорно.
Вообще эти механизмы не для использования в запросах, это уже люди так захотели.

С БСПшной реализацией случаются косяки перед записью. Да и плюх от истории данных больше и я про это уже писал
Версионирование объектов VS История данных
32. dsdred 3531 21.11.23 19:38 Сейчас в теме
(31) 1 попробуйте создать пустую базу на 8.3.20.
2 зайдите в sql и посмотрите есть там DataHistorySettingsExt
3 при помощи sql создать таблицу повторив её из пустой базы.

!Но сделайте это все на тестовой копии.
33. crazycat 222 21.11.23 19:41 Сейчас в теме
(32)Спасибо, пробовал создавать таблицу "вручную" с идентичной структурой - не помогло. Я так понимаю в какой-то из таблиц DataHistory* есть пометка о том, что именно для этих метаданных нужна таблица DataHistorySettingsExt.
34. dsdred 3531 21.11.23 19:46 Сейчас в теме
(33) насколько понимаю структуру истории данных, метаданные для расширений должны лежать в _DataHistoryMetadataExtX1
35. crazycat 222 21.11.23 19:53 Сейчас в теме
(34) Кажется, только что получилось решить проблему, что сделал:
1. В старом расширении включил режим совместимости 8.3.20;
2. Cоздал справочник;
3. Включил у него Историю данных.
После этих действий справочник открылся нормально, до этого выполнял только пункт 2 и программа выдавала ту же ошибку.

Все это на платформе 8.3.23.1912
36. crazycat 222 21.11.23 19:58 Сейчас в теме
(34) Да, теперь и после добавления нового расширения ошибки нет. Попробую вывить что поменялось кроме добавления самой таблицы.
37. dsdred 3531 21.11.23 20:28 Сейчас в теме
(36) попробуйте выявить закономерность и отправить в 1с.
В наших интересах чтобы новые механизмы становились надёжными.
43. igvlg 28.11.23 14:43 Сейчас в теме
1. Тестирование и исправление с одним пунктом "Реструктуризация таблиц базы данных"
должна появится надпись при реструктуризации содержащая "новая версия"
2. удалить расширение и добавить, при добавлении должны создаться таблицы по DataHistory.... , 4 штуки
46. dsdred 3531 28.11.23 15:11 Сейчас в теме
(43)я правильно понимаю. Это лечение ошибки из (5) сообщения?
44. igvlg 28.11.23 14:54 Сейчас в теме
Скрин
Прикрепленные файлы:
45. igvlg 28.11.23 14:55 Сейчас в теме
Скрин 2
Прикрепленные файлы:
47. Aleskey_K 35 30.11.23 07:47 Сейчас в теме
Как вариант, можно попробовать удалить часть истории, без вмешательства в SQL, платформенными методами вот этой обработкой: https://infostart.ru/1c/tools/1184565/
48. dsdred 3531 30.11.23 08:10 Сейчас в теме
(47) неполучится. Тут ошибка была в таблице с метаданными.
История чистится в других таблицах не затирая метаданные.
Оставьте свое сообщение