Решил покопаться замечательной утилитой V8TableSizes.exe в своей файловой базе, написанной на БСП, проверить что же она так растет, и каково же мое удивление что размер регистра продаж и даже регистра версий объектов ничтожен по сравнению с _SYSTEMSETTINGS ! у меня она почти 2гб ! при общем размере базы 2,7 гб. к слову версии объектов 280мб... Посмотрел что же это за зверь такой и: нашел хорошую статью
http://langslab.com/ebooks/prof-dev2/tome2/pr-dev-t2-ch23 _SystemSettings – эта таблица содержит хранилище системных настроек;
и что же там храниться? что же это за огромные настройки.. у меня же не +100500 юзеров, а всего лишь порядка 15-20ти.
Помогите как понять что конкретно там храниться, как это посмотреть, как понять что можно урезать чтобы сократить эту таблицу.
База разработана с 0 на базе БСП.
(13) Восьмой, мне лень и некогда ) есть более интересные темы про которые можно написать статью )
А вообще если у кого "растет" ) прилагаю обработку которая почистит эти записи средствами платформы, там же удаление истории работы пользователей (для УФ), так как она тоже растет и не чистится по всей видимости. Писалось для себя и за 5 минут, так что ни на что не претендует...
ПС: База сразу не "похудеет", нужно после очистки настроек, зайти в конфигуратор и сделать тестирование и исправление с флагами реструктуризации и сжатия
База сразу не "похудеет", нужно после очистки настроек, зайти в конфигуратор и сделать тестирование и исправление с флагами реструктуризации и сжатия
ну это аналог шринка пустых записей для файловой, это понятно.
Непонятен сам смысл этой затеи с _SYSTEMSETTINGS и её неконтролируемого роста, да еще и пущенного на самотек...
она не дает нам инструментов управления системными таблицами базы
Потому что не может сделать нормально такие инструменты. Но это в общем.
А в частности - есть подозрение, что это не "рудимент", а задел для каких-то фич в 8.3 и выше, но которые заброшены до лучших времен. Но потом могут выстрелить из пушки.
Вкратце опишу тут, свою историю и наработки:
У меня не разворачивался dt-файл на файловой базе. По публикации определил, что база при загрузки ДТ в файловую валится на 'CRE ATE INDEX _SystemSett_BySepUse_LL, _SystemSett_ByKey_SSS, _SystemSett_BySepUse_LL, _SystemSett_ByKey_SSS. Это индексы таблицы _SystemSettings (хранилище системных настроек). Через стандартный механизм БП 3.0 (скорее всего это стандартный механизм БСП) очистил все настройки всех пользователей и база спокойно поднилась на файловой.
Пользуясь наработками AllexSoft сделал "АнализХранилищаСистемныхНастроек.epf" который тупо выводит все настройки на экран. Анализировать надо выгружая в Excel. Лично я упорядочил по колонке "КлючОбъекта" и визуально просмотрев понял, что у меня слишком много записей ОбщаяФорма.Вопрос/00e05cce_65f2_4b0c_9219_9ecf5e713334/Такси/НастройкиОкна и тоже самое без слова "Такси". Переделал обработку AllexSoft под свою ситуацию (УдалениеДанныхФорм (1) мой.epf). Также добавил туда кнопку "Очистить все настройки не существующих пользователей". Правда эта кнопка почему-то удалила настройку панели разделов показывать "Картинка и текст", "Текст" или "Картинку". Не стал разбираться почему, т.к. для меня это не критично. Кроме кнопок "Удалить данные форм метод2" и "Очистить все настройки не существующих пользователей" ничем не пользовался.
По количеству записей: уменьшилось примерно на 40%. Причём в SQL варианте таблица _SystemSettings у меня занимает мало место (что-то около 400 МБ), а после очистки уменьшилась всего на 20 МБ, но в файловом варианте с размера >4ГБ уменьшилось до 1,9 ГБ и база спокойно развернулась.
(97) klinval, спасибо, полезное замечание, особо для пользователей интерфейса такси.. ибо моя обработка была заточена только по УФ. По поводу сохранения кодом настроек форм, я находил, отключил.. темп появлений записей поубавился конечно, но проблема все еще где то есть.. лень искать пока ) попробую поискать по "КлючСохраненияПоложенияОкна = Строка(Новый УникальныйИдентификатор);"
(97) klinval, спасибо за обработку!
Немного развил её и "причесал":
пользователя можно выбрать из списка пользователей (да, требуется справочник Пользователи, но он и ранее подразумевался);
добавлена возможность указать строки, по вхождению которых будут удаляться настройки.
Новая версия прилагается. Надеюсь, кому-то пригодится.
(3) SamNeSvoy, спасибо за ссылку, почищу обязательно, но вот бы еще узнать откуда ноги растут.. найти по УИДу окно которое плодит настройку... вот как это сделать
И так, что оказалось:
Если у вас конфа на базе БСП, как и у меня, то есть и все типовые на УФ (проверено на ут 11.1) то:
1. открываем Общие формы - ПечатьДокументов
2. В свойствах формы видим настройку
АвтоНавигационнаяСсылка = Истина
АвтоматическоеСохранениеДанныхВНастройках = Использовать
То есть что получается, каждый раз открывая эту общую форму (печатая документ) создается форма ПечатьДокументов с динамически сгенеренной ссылкой и при закрытии формы эта ссылка сохраняется в ХранилищеСистемныхНастроек
с миллионами вот таких 0978abfb_8f52_4070_aa7e_849dbe44c184/НастройкиОкна записей
Разумеется эти настройки никогда не будут считаны, а хранятся в базе мертвым грузом.
Что делать:
АвтоматическоеСохранениеДанныхВНастройках устанавливаем в Не использовать
ПС: у меня база похудела до 800мб, с 2,7 гб! просто почистив эти записи
Вот такой вот баг, по всей видимости существующий в БСП давно и до текущего дня не исправленный
ПС2: Баг работает как на 8.2 (хоть там нет свойства АвтоНавигационнаяСсылка, но все равно он ее генерит рандомно по умолчанию) так и на 8.3 где это свойство есть Истина
АвтоматическоеСохранениеДанныхВНастройках устанавливаем в Не использовать
и да, это не работает. И 1С отказывается, как нам сообщили, это исправлять. Но упорно продолжает использовать в БСП (даже после полной переработки под 8.3) все ту же запись данных общих форм.
У меня _SYSTEMSETTINGS так же огромных размеров (конфа самописная), но у всех форм АвтоматическоеСохранениеДанныхВНастройках = НеИспользовать... Как быть?
(7) Aleksey19891, а каких записей там больше всего?
(8) Arxxximed, Tool 1CD и утилитка по определению размеров таблиц в базе V8TableSizes
по поводу как обнаружил, понял что это какая то общая форма (так как идентификаторы постоянно разные были, и я их попробывал в базе поискать и их небыло - вывод что они генерятся каждый раз разные, это не ссылки на объекты данных), которая сохраняет настройки... понял так же что она из БСП, так как я никаких возможностей по сохранению настроек форм не использовал...
так как записей было очень много, я понял что этой формой пользуются часто, знаю специфику работы с базой определил круг форм которые часто открываются... потом почистил все настройки (в копии разумеется), ну и открывал подозрительную форму - смотрел появились ли искомые записи в таблице... ну и нашел эту форму ПечатьДокументов, ну а дальше дело техники внимательно проанализировать как идет сохранение настроек и создание (вызов) формы
Записи, так же, как и у Вас, связаны с настройками окон, форм. При этом свойство АвтоматическоеСохранениеДанныхВНастройках = НеИспользовать, как я уже писал выше.
(10) Aleksey19891, вполне возможно у тебя сохранение в коде, анализируй) где то оно сохраняется же! вот методику как я нашел описал в (9), можешь попробовать аналогично... если у тебя другой случай, то отпишись, думаю интересно всем будет
Ради интереса проверил в актуальной на данный момент УТ:
Управление торговлей, редакция 11.1 (11.1.4.10)
баг присутствует
Думаю что и в БП 3.0 и в ЗУП 3.0 он тоже имеется
спасибо за наводку, у меня в этой таблице, что я смог развернуть в файловом варианте, дальше 1с отказалась работать :)
Таблица: _SYSTEMSETTINGS
Описание: ХранилищеСистемныхНастроек
Размер: 4 910 466 240
Записи: 365 487 552
BLOB: 387 833 600
Индексы: 4 157 145 088
И это на 12 пользователей, которые пользуются всего 2 справочниками и 6 документами :)
она еще, когда мы работали в файловом варианте разбухла на глазах до 4,5 гигов, причем dt весил 220 мегабайт. просили разобраться никто не дал ответа вразумительного.
перешли на клиент-серверное решение.
сейчас решили обновить конфу, упс не сказал УНФ 1.4 с дописками, 1с-ники попросили dt выгрузить и потом не смогли развернуть в файловом варианте, выдает ошибку:
Ошибка информационной базы. В информационную базу загружены не все данные.
Нажимаю подробно:
Ошибка загрузки информационной базы. В информационную базу загружены не все данные
по причине:
Ошибка СУБД:
Превышен максимально допустимый размер внутреннего файла 'E:\base/1Cv8.1CD'
по причине:
Превышен максимально допустимый размер внутреннего файла 'E:\base/1Cv8.1CD'
спасибо за Tool_1CD сейчас выгрузил отчет из нее в *.xml файл данной таблицы, он весит 1Гиг :)
взял последний вариант файловой БД и на скорую руку сделал, что выше написано, база уменьшилась до 1Гига!!!
кстати вопрос, подобно можно проделать в клиент-серверном варианте?
(21) Shaka13, можно в клиент серверном, просто чистишь всю таблицу _SYSTEMSETTINGS средствами скуля и все.. там все записи настройки различные (окошек в основном), так что можешь удалять..
ПС: хотя обработка которую выложил работает и в клиент серверном варианте
(23) AllexSoft, вечером попробую вашу обработку на клиент серверном-варианте, плюс тестирование и исправление, сжатие не доступно.
у нас крутится на Linux + PostgreSQL
сейчас как средствами скуля сделать сжатие
(25) Shaka13, на клиент-серверном я бы просто очистил эту таблицу средствами администрирования скуля.. в постгрес есть же утилитка позволяющая это делать
Кстати, в моем случае настройки эти до сих пор появляются.. видимо еще где то в БСП есть подобная бяка ( причем замечено что записи в этой таблице могут какием то образом размножаться, после тестирования.. то есть глядишь до тестирования скажем размер таблицы 50мб, после тестирования уже 150! думаю все дело в реструктуризации этой таблицы или в реиндексации, вполне может быть что и в платформе там есть баги.. 8.2.19 на данный момент у меня
1 день полет нормальный, вчера вечером провел препарацию на боевом сервере, база уменьшилась до 1,3 гига в файловом исполнении, кстати в скулевском тоже стала такого размера, сейчас накачу релиз до последнего в надежде, что этот баг пофиксили. еще раз спасибо за правильный путь!
(30) TODD22, да, в твоем случае может и пол часа идти и больше.. так что можешь сходить на обед ) не забудь ТИИ как я писал в (14) иначе чуда не будет (
(33) TODD22, писалось для файловой.. работать должно и на клиент-серверной, вон у (25) Shaka13 сработало и на клиент-серверной. На файловой будет ОООООЧЕНЬ долго все это делать.. могу новую версию так сказать выложить) она побыстрее делает. Надо?
В моем случае минут 15 делало 2Гб.. в вашем 50Гб.. вот и посчитайте время - это для той обработки что сейчас выложена)
(34) AllexSoft, файловая база 6 Гб. Это 50+ она весит рабочая. После выгрузки dt и новой загрузки база становится 6Гб.
Можно новый вариант обработки? Может быстрее дело пойдёт.
Нажимать "Удалить данные форм метод 2".. причем удаляет порциями.. размер порции указан наверху) придется эту кнопку нажимать несколько раз, зато вы будете чувствовать что процесс идет )) Когда увидите что после очередного нажатия процесс проходит быстро и 1с не зависает в ожиданиях - значит все удалили, можно идти в конфигуратор и делать ТИИ
(43) albobm, да что вы) вы хоть почитайте пост (9) как я ее искал, там никакой ошибки записи быть не могло, все происходило в тестовой базе на локальном компе, в "стерильных" условиях.. чистилась полностью вся таблица, открывалась форма печати несколько раз, база закрывалась, смотрелось что появилось в таблице.. база 100% без ошибок, работает она кстати в реальных условиях не по сети, там тонкие клиенты через апач, так что таких критических сбоев записи там нет априори.. + эта же ошибка проверялась на БП 3.0 (файловая) и УТ 11(серверный вариант) - в рабочих условиях и в тестовом режиме на локальном компе. Так что ваша ссылка не по теме. Уж поверьте, я все перелопатил прежде чем что-то писать.
+ эта же ошибка проверялась на БП 3.0 (файловая) и УТ 11(серверный вариант)
Эта ошибка - с таблицей _SYSTEMSETTINGS, - пышным цветом расцвела именно в период массового УФ.
До этого была "Не удалось зафиксировать файл базы данных".
И вполне возможно, что ошибка была заложена изначально в платформу 8.х, а сейчас просто 1С не в состоянии переписать платформу с коррекцией багов.
Но это никак не отменяет вопроса - а зачем данные-то форм писать и хранить (тем болеее они УФ)? И в ТИИ до сих пор нет даже очистки таблицы _SYSTEMSETTINGS, если пустой она является рабочей.
Возможно ))
Возможно, что и не связаны никак эти две проблемы.
Но тут темный лес, который 1С даже не собирается расчищать, или хотя бы, признать, что лес - непролазный ("ошибка _SYSTEMSETTINGS существует, решается методом очистки таблицы").
А уж встроить очистку системной таблицы в ТИИ... это вообще практически ничего не надо - строчка кода и последнюю циферку в релизе платформы изменить ))
На тестовой базе на СУБД кое как сделалась очистка порциями. После этого перегрузил в файловую, сделал ТиИ. База с 6Гб стала 1.2Гб. Таблица индекса с 4Гб до 2 Мб.
Но на сервере в файловой базе с первой обработкой процесс ещё не закончился.... :(
(49) TODD22, ну вот) все хорошо.. первую можете вырубить.. она всю оперативу скушала по всей видимости. Поэтому я вам дал вот версию обработки которая удаляет порциями, а то у вас слишком запущенный случай =) Так что пробуйте на вашей большой базе тоже порциями удалять
Поэтому я вам дал вот версию обработки которая удаляет порциями
это очень опасно в 1С - сразу читать и модифицировать неограниченные объемы записей (сколько есть в таблице).
Особенно системной таблицы - в случае переполнения памяти возможна битая структура базы (таблицы).
(50) AllexSoft, Не ОЗУ всю не съела. И наконец то закончился процесс. Когда точно закончился я не смотрел. Сделал ТиИ. Вроде пока нормально.
Завтра будем тестить решило или нет это нашу проблему(с задержками при некоторых операциях: печати и формирование документов).
посмотрел настройку АвтоматическоеСохранениеДанныхВНастройках в форме печать документов:
в УТ 11.1.4.11 стоит использовать,
в УТ 11.1.9.51 уже не использовать,
видимо 1с так пофиксило проблему,
я часто использую АвтоматическоеСохранениеДанныхВНастройках - Использовать в обработках, теперь буду включать эту настройку только если без нее никак не обойтись
А почему эта проблема проявляется не у всех при ис пользовании одинаковых конфигураций?
Эта проблема только при использовании БСП (т.к. проблема в этой самой "АвтоматическоеСохранениеДанныхВНастройках", некорреткно пишушей данные в таблицу БД), и только при использовании в ней общих печатных форм.
Видимо, далеко не все пользуют.
(62) reznic, все зависит от конкретной конфигурации и ее релиза. + на клиент-сервере проблема выражена в меньшей степени из за меньших проблем с индексацией этой таблицы..
(63) AlexO,
ну раз вы это выяснили может мне из этого топика удалится? я вот ничего такого не говорил что "не влияет релиз конфигурации" - как раз таки влияет..
ПС: прошу вас не флудить тут, все таки топик не в ветке Life, так что пишите только если что то знаете на 100% и можете доказать фактами, а не пустословием и предположениями..
У меня _SYSTEMSETTINGS так же огромных размеров (конфа самописная), но у всех форм АвтоматическоеСохранениеДанныхВНастройках = НеИспользовать...
нуну, не судьба заглянуть в модуль формы и увидеть что там прописано сохранение тех же настроек при закрытии формы только кодом ;)
при чем тут индексация? Размер таблицы растет, а не её индексация.
я сказал что на файловой усугубляется проблемой с индексацией.. что количество записей растет хоть в клиент-сервере хоть в файловой - это само собой..
как хотите, в поиске реальной причины увеличения размера таблицы и её устранения вы участвовать все равно не хотите.
создайте себе отдельную ветку и участвуйте.. если вы посмотрите кто ветку начал, то вы уведите мой ник.. Я уже расписал из за чего данная проблема и что делать и даже обработки нужные дал.. думаю обсуждать тут больше нечего, а если все же хочется - прошу создать свой топик, я там тоже зайду и пообсуждаю ошибки от 1С и не только эти, могу еще подкинуть идею на тему "где растет"
ПС: прошу больше не флудить, народ потом не найдет нужной инфы
ну раз вы это выяснили может мне из этого топика удалится?
как хотите, в поиске реальной причины увеличения размера таблицы и её устранения вы участвовать все равно не хотите.
я вот ничего такого не говорил что "не влияет релиз конфигурации" - как раз таки влияет..
вообще никак не связана с вопросом ( 62)
А почему эта проблема проявляется не у всех при ис пользовании одинаковых конфигураций?
и с ответом ( 65)
Эта проблема только при использовании БСП (т.к. проблема в этой самой "АвтоматическоеСохранениеДанныхВНастройках", некорреткно пишушей данные в таблицу БД)
(70) reznic, думаю ответ в (61), все зависит от релиза.. когда я проверял и боролся с проблемой она проявлялась на УТ 11 и БП 3.0 + самописка на базе БСП.. сейчас вот сообщают что вроде исправили в УТ.
ПС: другое дело что не замечают и не задумываются почему базы пухнут.. считают "ну это же УФ! наверное так и должно быть"
Не носит потому, что не все используют механизм общих форм в БСП. Или с разной активностью.
Мы вообще из БСП УФ не использовали - вы думаете, у нас когда-либо всплыла бы даннная проблема?
это не праздное любопытство, в далеком прошлом занимался 1С, и сейчас нет нет да открываю конфигуратор :)
БП 3.0 поставил еще в период ее теста и работает она по настоящее время, так же стоит документооборот 1.4
на протяжении всего времени неконтролируемого роста баз не было, хотя обновления ставим регулярно, и платформу обновляем регулярно
Я не ставлю под сомнение что проблема есть (много их видел), но может все же она не из за БСП в том виде в каком Вы ее представляете? Почему исключаете вариант того что у Вас просто стоит проблемная версия платформы (сервера 1с)?
(72) reznic, думаю это знает лишь 1С на 100%, я могу только показать то что получилось у меня.. но все же из за БСП, не изза платформы, я ведь у себя эту проблему убрал просто отключив автосохранение в форме где оно не надо. А на платформах и на 8.2.18, 8.2.19, 8.3.4, 8.3.5 это те платформы которые я тестил и везде проблема была.. да и она собственно больше логическая, чем классический "баг". Просто нельзя генерить рандомно идентификаторы форм и сохранять настройки у этих форм - вот и вся проблема
Как раз из-за платформы, о чем пишу вам уже 10-ое сообщение! В данном случае у 1С на уровне платформы заложено - писать данные формы по накопительной в таблицу _SYSTEMSETTINGS (это ведь не регистр). И обратное (что данные пишутся уникальные, т.е. перезаписываются для формы, т.е. расширения не происходит) - никто еще не предъявил.
Я и писал, что вы проблему не поняли до конца.
А вот почему 1С сделал именно ТАК - это и есть и причина, и правильное решение данного вопроса.
(88) AllexSoft, Ещё одну проблему решил твоей обработкой. В УТ 11 стала зависать форма документа ПТиУ при создании нового документа, зависала на 1-1.5 часа при открытии.
Почистил настройки пользователя. Всё заработало.
(89) TODD22, проблема та же - гигантская таблица непонятного назначения.
В файловом - превышение ограничения в 4ГБ на таблицу, в серверном - тормоза и долгая обработка/загрузка.
Никаких "еще одна проблема".
Примерно как у (89) зависало минут на 10 при создании нового ПТиУ (11.1.9.70 на пару гигов), но чистка обработкой (14) не помогла, помогло только когда подправил там и удалил настройки начинающиеся с "Документ.ПоступлениеТоваровУслуг".
Таких настроек было несколько, и подозреваю что проблема была не в самой разросшейся таблице настроек, а в том что в одной из этих настроек были багнутые НастройкиОкна или НастройкиФормы, но в отладчике по ним ничего не видно.
(91) mixa4, было такое тоже.. правда я такие настройки чистил через стандартный функционал БСП, в разделе Администрирование в закладке пользователей.. там как раз удобная формочка по просмотру и удалению\копированию настроек отдельных форм..
что вы переживаете? я что, отобрал пальму у вас? Или опорочил "супер" решение? Вообще, есть такая вещь на ИС - называется "статья". Вот там вы единолично пишите все, что и сколько пожелаете. И то - любой (и я тоже) будем вольны в комментах оставить свое мнение.
Или и тут я у вас "статью сплагиатил"?? Что б вы так возмущались - должна быть веская причина.
что вы переживаете? я что, отобрал пальму у вас? Или опорочил "супер" решение?
На примере последних трех ваших сообщений в этой ветке, вы забрали у многих занятых людей драгоценное время и нервы, заставив трижды открыть эту ветку в надежде прочесть полезную информацию и обнаружить там обычный треп и флуд "как наши корабли бороздят просторы большого театра..."
Коллеги поддерживаю ТС, ведь решение рабочее, имейте уважение. Благодаря этому багу нас франчи наклонили на 200к чтоб перейти на серверное решение, я сам нашел решение и после исправления этой ошибки выяснилось, что можно было остаться на файловом варианте. Возможно 1С специально не закрывает этот баг, чтоб таких лохов как мы наклонять :)
и я его поддерживаю. Я против одного - что ТС нашел причину. Следствие, да исправил. И то костыль своего рода.
ведь решение рабочее, имейте уважение. Благодаря этому багу нас франчи наклонили на 200к чтоб перейти на серверное решение
не тут, так в другом месте и по другой причине бы вас "наклонили". Затыков по производительности в 1С море разливанное, франчи всегда агитируют на "переходить на более современное и мощное железо", ибо это проще.
По-моему, это совсем о другом.
что можно было остаться на файловом варианте
В файловом куча проблем и без этого с производительностью. И вы что - УФ в файловой базе запускаете? Тогда не
чтобы поиметь данную "ошибку", вы должны запускать базу в УФ, чтобы запустить базу в УФ - должен быть сервер-клиент.
Единственный вариант с файловой - запустить сервер в файловом варианте. Т.е. у вас "на сервер" уже перешли.
веская причина одна - тут решают проблемы, а не высказывают мнение, а вы просто засоряете ветку. Потом кто зайдет за помощью могут не обнаружить нужного ответа из за вашего флуда. У вас как я понял этой проблемы нет - значит и помощь по теме топика вам не нужна.
AllexSoft спасибо! Ваши обработки и описание подтолкнули к правильному решению проблемы (обработку пришлось переписывать + вроде нашёл в базе как устранить проблему навсегда: нужно в ОбщаяФорма.Вопрос запретить генерировать каждый раз новый ключ). Хотел спросить:
0. Вы вообще собираетесь оформлять полноценную публикацию по данной проблеме? Просто я долго искал решение и чисто СЛУЧАЙНО нашёл на данную тему! Явно нужна полноценная статья!
1. Что вы удаляете поиском по "/НастройкиОкна" и длиною 50 символов? Просто у меня вроде такой проблемы нет. "ОбщаяФорма.Вопрос/" длиною 68 или 74 символа - есть, а что вы пытаетесь удалить "/НастройкиОкна" не понимаю...
2. ИсторияРаботыПользователя в базе данных как объект будет называться? ХранилищеСистемныхНастроек называется _SYSTEMSETTINGS, а историяРаботыПользователя так-же?
(93) 1. Сейчас глянул в базе, у нас настройки длиною 50 символов и содержащие "/НастройкиОкна" не такие уж и массовые. Есть несколько - но это не критично. Как я понял вы хотели данным кодом удалить настройки вида "534f1fcc_2982_4ce4_ad0d_7bffb4e4fe47/НастройкиОкна". Правильно я понял вашу задумку?
Проблема в том, что ваш код сотрёт и настройки вида "Справочник.Банки.Форма.ФормаЭлемента/НастройкиОкна", и т.к. у нас проблема не столь массовая пришлось не очищать "/НастройкиОкна"
2. Нашёл где хранится история работы пользователей: таблица _UsersWorkHistory.
(94) klinval, да, в моем случае проблема именно с записями типа 534f1fcc_2982_4ce4_ad0d_7bffb4e4fe47/НастройкиОкна
с другими записями такой массовой проблемы нет, с вопросом тоже была вроде, но как то очень мало и решение аналогично тому что я писал выше.
По поводу настроек окна банков, для моей задачи не актуально было, поэтому обработку по очистке настроек выложил как есть, написано на коленке для разовых целей.. кому надо тот для себя допилит ) все равно в эту тему только программисты смотрят..
отдельную статью писать не хочу, времени нет, да и тема слишком узкая для целой статьи.. если будете писать подобную статью, то могу еще намекнуть на то место где "растет" если используете систему версионирования и как ее подправить )
(95) AllexSoft, похоже тут тема не только узкая, но и у всех всё по разному. У вас основной гемор был с настойками вида 534f1fcc_2982_4ce4_ad0d_7bffb4e4fe47/НастройкиОкна, а у меня с ОбщаяФорма.Вопрос/00e05cce_65f2_4b0c_9219_9ecf5e713334/Такси/НастройкиОкна. Например есть публикация http://infostart.ru/public/200268/, её можно найти через поисковик, как я и нашёл её, но она более общая. Получается, что на форуме (т.е. тут) фиг найдёшь эту тему, а если создать публикацию, то она скорее всего никого не заинтересует, будет мало просмотров и тогда её возможно тоже не найдёшь. Просто я на эту тему попал через эту тему, которую в свою очередь нашёл через яндекс, т.е. другими словами заглянул сюда случайно. А тема очень сильно помогла.
Нужна или не нужна публикация - вот в чём вопрос)
могу еще намекнуть на то место где "растет" если используете систему версионирования и как ее подправить )
Версионированием не пользуюсь (использую платный журнал истории), поэтому проблем с этим нет))
(94)
Для MS SQL удаление строк вида "534f1fcc_2982_4ce4_ad0d_7bffb4e4fe47/НастройкиОкна", не затрагивая подобные строки "Справочник.Банки.Форма.ФормаЭлемента/НастройкиОкна", у которых совпадает длина и которые будут удалены приведенной внешней обработкой 1С.
Delete ИМЯ_ВАШЕЙ_БАЗЫ_ДАННЫХ.dbo._SystemSettings
where _ObjectKey LIKE '________[_]____[_]____[_]____[_]____________/НастройкиОкна';
PRINT 'Number of rows deleted is ' + CAST(@@ROWCOUNT as char(3));
Легко модифицируется/дополняется для подобных строк
"ОбщаяФорма.Вопрос/00e05cce_65f2_4b0c_9219_9ecf5e713334/Такси/НастройкиОкна"
з.ы. ТС спасибо за поднятую тему и прекрасную обработку!
кучу времени потратил на решение вышеописанных проблем, пока не нашел эту ветку.