Казалось бы, тема давно разжевана, пережевана, много различных методик лечения от вегетарианских зачисток кеша, до вполне себе серьезных манипуляций с таблицами MS SQL.
Бэкграунд ситуации: УПП (1.3.113.4), платформа 8.3.13.1644, распределенная база (центральная и 2 периферийные базы). В какой-то момент после динамического обновления и попытки входа в режиме Предприятия в центральной базе появилась ошибка на скриншоте, периферийные базы обновление не получили. Бэкапов еще делать не начинали, базу внедрили в начале года и впопыхах об этом важном моменте как-то забыли. И хорошо что случилось это в новогодние праздники, иначе пользователи меня бы растерзали...
Пробовались все методики, описанные у Гилева тут и тут.
В моем случае ни один из перечисленных методов не принес долгожданного обретения душевного спокойствия и восстановления гармонии с окружающим миром...
Переписывание содержимого таблицы Config в ConfigSave платформа даже не почувствовала, видимо до анализа таблицы ConfigSave даже не доходило, появлялась все та же ошибка потока.
От отчаяния был даже переписано содержимое таблицы Config взятой из периферийной базы, но опять ошибка потока. Вспомнил что кто-то советовал переписать и содержимое таблиц Params и DBSchema, изменения возымели действие и при запуске уже появлялись ошибки отсутствия каких-то полей, которые я пытался восстанавливать по методике //infostart.ru/public/391766/. Максимум что мне удалось это запуск конфигуратора, но запуск в режиме Предприятия все равно заканчивался ошибкой модуля и ругательством про то, что нет возможности записать пользователя в таблицу. Накатывание конфигурации самой периферийной базы так же было в пустую, никаких изменений сравнение конфигураций не выявляло, что довольно объяснимо...
Пытался анализировать пользуясь SQL Server Profiler что же 1С при запуске пытается сравнивать или какую информацию считывать из базы перед тем, как выдать сообщение про проклятый поток, увы в силу малого опыта работы с SQL сервером выяснить это так и не получилось, ситуацию усугублял фон от активно работающих с другими базами пользователей.
Пришлось искать какие-то другие варианты, была попытка даже анализировать алгоритм создания записей в таблице Config путем создания в пустой базе какое нибудь объекта. Но никакой полезной информации или каких либо закономерностей так и не получилось получить, в прочем знакомыми показались записи увиденные в таблице Params (рис.2)
в памяти всплыла методика борьбы с нарушением целостности структуры конфигурации описанная в статье //infostart.ru/public/76626/ единственное что смущало, что в далеком 2010 году такие записи создавались в таблице Config, в то время как сейчас я вижу их в таблице Params, тем не менее вариант было решено адаптировать под сегодняшние реалии и применить, за основу был взят скрипт пользователя denp2002 представленный в комментариях к статье по ссылке выше.
Собственно решение...
Применяем нижеприведенный скрипт:
use [НазваниеВашейБазы] BEGIN TRANSACTION delete from [dbo].[Params] where FileName in ( select c.filename from Config as c inner join ( select * from ( SELECT max( modified ) over (partition by substring(FileName,0,37)) as mdt ,SUM(1) over (partition by substring(FileName,0,37)) as sm, substring(FileName,0,37) fs , substring(FileName,48,37) sc , * FROM [dbo].[Params] WHERE FileName Like '%_dynupdate_%')as a where a.sm != 1 ) as b on b.mdt != c.modified and b.FileName = c.FileName) delete from [dbo].[Params] where FileName in ( select filename from ( select MAX(Modified) over(partition by substring(a.filename, 0, 37) ) as mdt , * from [dbo].[Params] as a where LEN(a.FileName) = 36 or a.FileName like '%_dynupdate_%' ) as b where b.mdt != b.Modified ) update [dbo].[Params] set filename = substring(filename, 0, 37) where FileName like '%_dynupdate_%' commit
Результат выполнения:
После этого без каких либо сообщений открываются и Конфигуратор и Предприятие, как будто ничего и не было до этого...
Бинго!
