Как-то случилась у нас на предприятии «беда». Беда эта была связана с базой данных 1С Предприятия 8.2 на MS SQL 2008. Из отделов начали жаловаться на ошибку табличных частей. С программистами 1C, пытались решить данную проблему в кротчайшие сроки, но ничего на ум особого не приходило. Сам я раньше не сталкивался с такой проблемой, поэтому пришлось гуглить и искать решение проблемы. В основном попадались обрывки фраз, которые когда-то люди пытались что-то сделать, а так и не сделали. Все думаю знают, что 1С это вещь такая без которой нельзя, а хотелось бы порой… Много лишнего, проблем (недописок), не правильной структуры и т.п.
Ошибка которая начала появляться:
Ошибка хоть и не была критичной, но не давала работать людям. Были предприняты попытки связаться с интегратором, чтобы он хоть чем-то помог. В основном поступали предложения о том, чтобы загрузить Конфигуратор и попытаться Выгрузить/Загрузить базу в .dt-файл, а также Отсоединить/Присоединить. Из-за большого объема данных, выгрузка dt-файла, заняла бы на нашем даже производительном сервере по меньшей мере сутки! Это нас не устраивало естественно. Около часа я искал в интернете решение проблемы и тут от интегратора получил сообщение следующего содержания:
Естественно я до этого почему-то не догадался. Был взят бэкап недельной давности, а точнее за 25 число и загружен в демо базу. В табличной части была найдена данная таблица, которая содержала порядка 2500 строк информации. А дальше, дальше я уже понял, что нужно делать. Распишу по пунктам, мало ли сам забуду или кому-нибудь пригодиться.
1. Самое немаловажное это бэкап где нет битых табличных частей и структур. Если он у вас есть, значит переходим ко второй части. Если нет, то думаем кого пинать и ругать, т.к. это неотъемлемая часть в сохранности информации в компании.
2. Заливаем бэкап в демо базу. Я не использовал консоль, у меня есть Microsoft Managment Studio 2008, поэтому мне было проще. Кто любит извращаться с помощью консоли — Бога ради, пусть делает запросы с помощью нее.
3. Собираем все ошибки воедино, т.е. те которые появляются у пользователей на Недопустимое имя объекта. У меня их обнаружилось всего две, но есть подозрение, что их гораздо больше. (Ошибка таблицы "_Document179_VT3549" и "_Document188_VT3785").
4. Смотрим в «Плохую базу» есть ли такие табличные части. Если нет, а их скорее всего нет делаем следующее в демо базе: Находим строку dbo._Document179_VT3549 --> Нажимаем правой кнопкой мыши и выбираем Создать сценарий для таблицы --> Используя CREATE --> Новое окно редактора запросов.
Появиться окно с запросом CREATE:
Выполняем его на «Плохой базе» предварительно изменив USE [Torg_demo] на USE [Torg]. В результате этого запроса, будет создана таблица. Проделываем данный пункт со всеми табличными частями к которым утрачен доступ и которые требуется создать заново. Напомню мне нужно было создать 2-е таблицы "_Document179_VT3549" и "_Document188_VT3785".
5. В «Здоровой базе» — демо, делаем следующее с таблицами которые нам требуется восстановить. Находим строку dbo._Document179_VT3549 --> Нажимаем правой кнопкой мыши и выбираем Создать сценарий для таблицы --> Используя SELECT, затем Используя INSERT. Должно появиться 2-а запроса (заготовки) к базе данных, которые обращаются к табличным частям. Их требуется объединить в один, по моему принципу: INSERT INTO <название таблицы> SELECT <имя столбца>,… FROM <название таблицы>. Данный запрос перенесет все данные которые были в демо базе в основную.
Пример:
Конечный вариант который получился у меня для одной таблицы (проделываем со всеми, то же самое по-аналогии):
После этого, можно расслабиться не на долго. Все должно работать. Табличные части восстановлены, запросы которые выполняют пользователи при обращении к базе данных проходят корректно, и клиент не ругается на ошибку СУБД. Надеюсь моя запись будет полезна кому-то.
P.S: бросать данную проблему при возникновении не стоит, т.к. можно «огрести» много проблем в дальнейшем.
P.P.S: прошу прощения, что нет картинок на данном этапе.
Ошибка которая начала появляться:
Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: Недопустимое имя объекта "_Document179_VT3549".
HRESULT=80040E37, SQLSrvr: SQLSTATE=42S02, state=1, Severity=10, native=208, line=1
Ошибка хоть и не была критичной, но не давала работать людям. Были предприняты попытки связаться с интегратором, чтобы он хоть чем-то помог. В основном поступали предложения о том, чтобы загрузить Конфигуратор и попытаться Выгрузить/Загрузить базу в .dt-файл, а также Отсоединить/Присоединить. Из-за большого объема данных, выгрузка dt-файла, заняла бы на нашем даже производительном сервере по меньшей мере сутки! Это нас не устраивало естественно. Около часа я искал в интернете решение проблемы и тут от интегратора получил сообщение следующего содержания:
Попробуйте залить в демо базу архив скажем недельной давности и проверить структуру таблиц, есть ли там например такая строчка "_Document188_VT3785"
Естественно я до этого почему-то не догадался. Был взят бэкап недельной давности, а точнее за 25 число и загружен в демо базу. В табличной части была найдена данная таблица, которая содержала порядка 2500 строк информации. А дальше, дальше я уже понял, что нужно делать. Распишу по пунктам, мало ли сам забуду или кому-нибудь пригодиться.
1. Самое немаловажное это бэкап где нет битых табличных частей и структур. Если он у вас есть, значит переходим ко второй части. Если нет, то думаем кого пинать и ругать, т.к. это неотъемлемая часть в сохранности информации в компании.
2. Заливаем бэкап в демо базу. Я не использовал консоль, у меня есть Microsoft Managment Studio 2008, поэтому мне было проще. Кто любит извращаться с помощью консоли — Бога ради, пусть делает запросы с помощью нее.
3. Собираем все ошибки воедино, т.е. те которые появляются у пользователей на Недопустимое имя объекта. У меня их обнаружилось всего две, но есть подозрение, что их гораздо больше. (Ошибка таблицы "_Document179_VT3549" и "_Document188_VT3785").
4. Смотрим в «Плохую базу» есть ли такие табличные части. Если нет, а их скорее всего нет делаем следующее в демо базе: Находим строку dbo._Document179_VT3549 --> Нажимаем правой кнопкой мыши и выбираем Создать сценарий для таблицы --> Используя CREATE --> Новое окно редактора запросов.
Появиться окно с запросом CREATE:
USE [Torg_demo]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[_Document179_VT3549](
[_Document188_IDRRef] [binary](16) NOT NULL,
[_KeyField] [binary](4) NOT NULL,
[_LineNo3786] [numeric](5, 0) NOT NULL,
[_Fld3787RRef] [binary](16) NOT NULL,
[_Fld3788RRef] [binary](16) NOT NULL,
[_Fld3789RRef] [binary](16) NOT NULL,
[_Fld3790RRef] [binary](16) NOT NULL,
[_Fld3791] [numeric](15, 3) NOT NULL
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO
Выполняем его на «Плохой базе» предварительно изменив USE [Torg_demo] на USE [Torg]. В результате этого запроса, будет создана таблица. Проделываем данный пункт со всеми табличными частями к которым утрачен доступ и которые требуется создать заново. Напомню мне нужно было создать 2-е таблицы "_Document179_VT3549" и "_Document188_VT3785".
5. В «Здоровой базе» — демо, делаем следующее с таблицами которые нам требуется восстановить. Находим строку dbo._Document179_VT3549 --> Нажимаем правой кнопкой мыши и выбираем Создать сценарий для таблицы --> Используя SELECT, затем Используя INSERT. Должно появиться 2-а запроса (заготовки) к базе данных, которые обращаются к табличным частям. Их требуется объединить в один, по моему принципу: INSERT INTO <название таблицы> SELECT <имя столбца>,… FROM <название таблицы>. Данный запрос перенесет все данные которые были в демо базе в основную.
Пример:
INSERT INTO [Плохая база].[dbo].[_Reference120_VT120]
([_Reference120_IDRRef]
,[_KeyField]
,[_LineNo1924]
,[_Fld1925RRef]
,[_Fld1926RRef])
SELECT
[_Reference120_IDRRef]
,[_KeyField]
,[_LineNo1924]
,[_Fld1925RRef]
,[_Fld1926RRef])
FROM [Здоровая база].[dbo].[_Reference120_VT120]
GO
Конечный вариант который получился у меня для одной таблицы (проделываем со всеми, то же самое по-аналогии):
INSERT INTO [Torg].[dbo].[_Document179_VT3549]
([_Document179_IDRRef
,[_KeyField]
,[_LineNo3550
,[_Fld3551RRef]
,[_Fld3552RRef]
,[_Fld3553RRef]
,[_Fld3554]
,[_Fld3555]
,[_Fld3556]
,[_Fld3557]
,[_Fld7555]
,[_Fld9166]
,[_Fld9167RRef]
,[_Fld9168RRef]
,[_Fld9169RRef])
SELECT
[_Document179_IDRRef]
,[_KeyField]
,[_LineNo3550]
,[_Fld3551RRef]
,[_Fld3552RRef]
,[_Fld3553RRef]
,[_Fld3554]
,[_Fld3555]
,[_Fld3556]
,[_Fld3557]
,[_Fld7555]
,[_Fld9166]
,[_Fld9167RRef]
,[_Fld9168RRef]
,[_Fld9169RRef]
FROM [Torg_demo].[dbo].[_Document179_VT3549]
GO
После этого, можно расслабиться не на долго. Все должно работать. Табличные части восстановлены, запросы которые выполняют пользователи при обращении к базе данных проходят корректно, и клиент не ругается на ошибку СУБД. Надеюсь моя запись будет полезна кому-то.
P.S: бросать данную проблему при возникновении не стоит, т.к. можно «огрести» много проблем в дальнейшем.
P.P.S: прошу прощения, что нет картинок на данном этапе.