Invalid object name 1c ошибка субд
Обновлено: 06.07.2024
Я занимаюсь программированием обслуживания довольно большого проекта, который был начат кем-то, кто теперь покинул компанию.
Я только что создал резервную копию одной из баз данных компании, а затем снова подключил ее к нашему тестовому серверу. Кажется, это работает нормально.
затем я прохожу обычную процедуру входа в систему программы, и эта часть также работает.
запуск той же функции в исходной базе данных отлично работает и возвращает данные, которые я ожидаю увидеть.
объяснения подобных ошибок, которые я нашел, похоже, относятся к схемам, но именно там все становится немного странным. Исходная база данных явно не есть любые схемы; в своей папке" безопасность "он просто имеет папку" Пользователи", содержащую dbo, и папку "роли", содержащую " роли базы данных" папка, с обычным db_owner и т. д. материал и пустая папка с именем "роли приложений".
папка безопасности в резервной копии и восстановленной базе данных полна всякого дерьма. Три пользователя в дополнение к dbo, папка "схемы", папка "сертификаты", две папки ключей шифрования. Я не могу их удалить.
из моего ограниченного понимания системы входа в систему SQL пользователь, в который я вхожу, получает не-dbo-разрешения из этой коллекции случайного дерьма, и поэтому ему отказывают в доступе к частям базы данных, принадлежащей dbo.
Если я правильно понимаю, вы выполняете процедуру (SomeProc) в базе данных (SomeDB), и это дает ошибку Invalid object name 'Informix.dbo.customer' ? Это просто означает, что SomeProc не может найти объект "клиент" в схеме под названием "ДБО" в базу данных "СУБД Informix". Для этого существует несколько возможных причин:
- объект не существует, возможно, потому, что схема и / или база данных не существуют
- объект существует, но пользователь, выполняющий процедуру, не имейте разрешение даже увидеть его
- объект существует, но база данных чувствительна к регистру, и некоторая часть имени не соответствует имени в вашем коде
вам нужно будет исследовать больше, чтобы узнать, какова причина в вашем случае, но как полная догадка, ваш производственный сервер имеет базы данных Informix и SomeDB, но ваш тестовый сервер имеет только SomeDB?
наконец, при публикации вопросов всегда включайте версию SQL Server (2000/2005/2008) и издание (Express, Standard, Enterprise); они могут быть очень важны, когда речь идет о схемах и разрешениях, потому что функции и поведение могут быть разными.
Это может быть проблема с владельцем объекта (SP в вашем случае). Проверьте владельца в SQL management studio
Как-то случилась у нас на предприятии «беда». Беда эта была связана с базой данных 1С Предприятия 8.2 на MS SQL 2008. Из отделов начали жаловаться на ошибку табличных частей. С программистами 1C, пытались решить данную проблему в кротчайшие сроки, но ничего на ум особого не приходило. Сам я раньше не сталкивался с такой проблемой, поэтому пришлось гуглить и искать решение проблемы. В основном попадались обрывки фраз, которые когда-то люди пытались что-то сделать, а так и не сделали. Все думаю знают, что 1С это вещь такая без которой нельзя, а хотелось бы порой… Много лишнего, проблем (недописок), не правильной структуры и т.п.
Ошибка которая начала появляться:
Ошибка СУБД:
Microsoft OLE DB Provider for SQL Server: Недопустимое имя объекта "_Document179_VT3549".
HRESULT=80040E37, SQLSrvr: SQLSTATE=42S02, state=1, Severity=10, native=208, line=1
Попробуйте залить в демо базу архив скажем недельной давности и проверить структуру таблиц, есть ли там например такая строчка "_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
После этого, можно расслабиться не на долго. Все должно работать. Табличные части восстановлены, запросы которые выполняют пользователи при обращении к базе данных проходят корректно, и клиент не ругается на ошибку СУБД. Надеюсь моя запись будет полезна кому-то.
Возникает у всех пользователей.
Кеш, tempdb чистили. Полное тестирование и исправление делали. Выгрузка базы в файл .dt. Создание новой БД и загрузка из .dt была
Ошибка осталась, появляется с разной периодичностью.
При использовании платформы 8.3.6.2390 и версии Бухгалтерия 3.0.44.115 таких проблем не было
На этом же оборудовании используется ЗУП 2.5 (1С 8.2) и самописная конфигурации (1С 8.3) с большой нагрузкой проблем нет
Нужно другой клиент. Лучше сиквел обновить
Поддерживаю, та же фигня.
Версии конфигурации, платформы и SQL такие же.
Другие базы работают нормально.
По похожим ошибкам вычитал что помогает перезапуск SQL сервера, но сейчас не проверить.
Вылетает исключительно на ФОНОВЫХ ЗАДАНИЯХ, у меня такое ощущение.
Ну и пару раз на ОбщийМодуль.ДлительныеОперации.Модуль(375)
Добавлю по конфигу: Сервер приложений 64бит, клиенты толстые и тонкие, терминал или напрямую, ОС WinXP 32, Win 7 32, Win7 64, Win2k3r2 64 (терминал). Даже 64бит клиент попробывали - одна фигня, ошибки Больше ни у кого ошибка не появляется?
Обновили Бух до последнего релиза (3.0.44.164), проблема осталась Нам в компании помогло Тестирование и исправление информационной базы - все галки. 2 дня полет нормальный. На сервере где установлен сервер 1С предприятия нужно установить Microsoft SQL Server Native Client 10.0 из дистрибутива MSSQL машину нужно будет перезагрузить. В системе должна появится программа: у нас даже после этих действий проблема осталась.
1С пишет: "В одной из ближайших версий будет исправлена." напишите пожалуйста полный текст tsql запроса с ошибкой и 3 до ошибки.
Мы рады проинформировать Вас о том, что 27.10.2016 была обновлена информация о следующих публикуемых ошибках:
С наилучшими пожеланиями, фирма "1С".
Подскажите на какую версию 8.3.8 можно откатиться чтобы эта ошибка не возникала?
Неточности СУБД базы данных (ошибка SQL) в программном продукте 1С: Предприятие 8
Данный материал будет полезен пользователям, столкнувшимся с неточностями в работе программных продуктов на платформе 1С: Предприятие 8.
На рисунке 1 приведен пример окна ошибки: Ошибка СУБД Ошибка SQL.
Почему возникают такие ошибки?
В первую очередь это обуславливается неправильной работой пользователей на местах с программами 1С. Экономия владельцев бизнеса на обучении своего персонала корректной работе с данным программным обеспечением, либо экономия на техническом оснащении, работа на устаревших компьютерах, применение близких к окончанию сроков эксплуатации жестких дисков через некоторое время могут вызвать крупные расходы. Неприятным результатом может стать простой бизнеса, а также утеря данных управленческого, бухгалтерского либо финансового учета.
Примеры источников ошибок в функционировании программ 1С и виды визуального выражения нарушения целостности БД (база данных):
аварийное завершение работы ОС с работающей программой 1С: Предприятие 8, в особенности во время формирования, проведения либо удаления файлов;
удаление и повреждение конфигурационных файлов в результате вмешательства со стороны пользователя либо техники;
приостановка процесса восстановления архивной информации;
отсутствие внешнего надежного напряжения питания;
присутствие файлов без нумерации, дат создания;
присутствие файлов с датой создания, которая не соответствует рядом стоящим файлам, к примеру, 2001 г. 01 ч. 01 мин. 01 с.;
присутствие операций без нумерации, дат создания;
недоступность ранее созданных файлов и операций;
отсутствие ссылок на объекты.
Таким образом, в первую очередь нужно завершить работу программы 1С.
После этого создайте копию БД (база данных) с повреждениями (для этого нужно сохранить базу в отдельный каталог на винчестере). Путь, ведущий к местонахождению БД (база данных), можно определить с помощью панели запуска 1С: Предприятие 8 внизу, найдите данный каталог на жестком диске и скопируйте его (смотрите рисунок 2).
Рисунок 2: Окно запуска 1С: Предприятие 8.
Далее протестируйте БД (база данных) на физическую целостность (на предмет «разрушения»). Чтобы это сделать, выполните переход к стандартной встроенной обработке 1С: Предприятие 8 по исправлению и тестированию неточностей – chdbfl.exe (загрузить для 1С: Предприятие 8). Данный документ должен присутствовать в каталоге с установленной программой 1С, найдите и выполните его запуск (смотрите рисунок 3).
Рисунок 3: Местонахождение документа chdbfl.exe.
Потом выбираем документ 1CV8.1 CD, который можно найти в каталоге нашей БД (база данных) с повреждениями, устанавливаем галочку «Исправлять обнаруженные ошибки» и жмем «Выполнить» (смотрите рисунок 4).
На проверку физической целостности документа БД (база данных) может уйти от 10 мин. до нескольких часов – это определяется объемом вашей БД (база данных) и количеством неточностей в ней. По завершении проверки обнаруженные неточности рекомендуется сохранить в отдельный документ для последующей экспертной диагностики.
Рисунок 4: Окно проверки физической целостности документа информационной базы
После этого зайдите в режим конфигуратора (смотрите рисунок 5) и найдите в нем сервисную утилиту “Тестирование и исправление информационной базы” (смотрите рисунок 6).
Меню – Администрирование – Тестирование и исправление
Рисунок 5: Конфигуратор
Рисунок 6: Окно тестирования и исправления БД (база данных)
Выберите такие пункты, как:
Реиндексация таблиц информационной базы – функция восстановления табличной части БД (база данных).
Проверка логической целостности информационной базы – функция проверки логической целостности БД (база данных).
Проверка ссылочной целостности информационной базы – тестирование внутренних связей таблиц, которые устанавливает программа 1С: Предприятие 8, проверка фактического существования элементов данных со ссылками в полях записи таблиц.
Перерасчет итогов – выполнение полного перерасчета итоговых данных.
Переключатель ниже, выбор пункта «Тестирование и исправление».
Операция «Тестирование и исправление» может длиться от 10 мин. до нескольких часов – это определяется объемом БД (база данных) и количеством неточностей в ней. По завершении проверки обнаруженные неточности рекомендуется сохранить в отдельный документ для последующей экспертной диагностики.
На следующем этапе закройте конфигуратор, откройте БД (база данных) в стандартном режиме и оцените произошедшие изменения с поврежденными файлами либо справочниками, сформируйте ключевые отчеты для сравнения. Если проблемы отсутствуют и все в порядке, смело продолжайте работу с БД (база данных). Если проблема с информационной базой все еще присутствует, приглашайте эксперта по 1С из обслуживающей компании «АйТи-Консалтинг», либо сразу обращайтесь в техническую поддержку 1С.
Внимательно изучите ситуацию, сделайте верные выводы: обеспечьте вашим работникам обучение корректной работе с программами 1С, купите новую технику на замену старой.
Если Вы слишком заняты и не можете тратить на это время, мы ждем Ваших обращений в сертифицированный центр обслуживания 1С - «АйТи-Консалтинг».
3. Также с этой ситуацией пересекается следующая ситуация:
10007066 Запись данных, содержащих колонки типа ХранилищеЗначения
Проблема:
При использовании СУБД MS SQL SERVER при записи объекта базы данных, содержащего несколько колонок типа ХранилищеЗначения, данные для которых получены из файлов, может происходить ошибка
Ошибка СУБД:Microsoft OLE DB Provider for SQL Server: String data length mismatchHRESULT=80004005и аварийное завершение работы программы.
Включив технологический журнал на время загрузки, можно определить таблицу, в которой содержатся такие хранилища. Найдите средствами MS SQL Server Query Analizer в этой таблице колонки типа image. Для каждой колонки типа image выполните запрос вида:
S_elect top 10 DATALENGTH(_Fld4044)
from _InfoReg4038
order by DATALENGTH(_Fld4044) desc
Нюансы: обратите внимание, что ”Стандартные проверки” платформой (chdbfl, в конфигураторе) упорно говорят, что с базой все ОК.
1С:Предприятие 8.2. Лицензия на сервер (x86-64)
По опыту проблема связана с хранением данных в реквизите хранилище значений либо наличием в таблице config двоичных данных БОЛЬШЕ 120 mb.
Обобщенные рекомендации, если рекомендации от 1С не помогли (проделать следующие действия в указанном порядке):
1. Выключить все фоновый задачи у всех баз
В 8.1.11 появился переключатель “запрет на фоновые задания” в
момент создания базы.
Готов пояснить, фоновые задания сами по себе не зло, но регламентные процедуры
с полнотекстовым поиском – вещь в себе – и память она может через какое время
съедать ресурсы rphost.exe, что на другие операции не останеться, и просто
базу блокировать
т.е. другими словами, после первого шага уже можно проверять – возможно проблема “уйдет”.
3) делаем бэкап средствами sql
Делать резервное копирование рекомендую при любых действиях, когда может потребоваться “возврат” к предыдущему состоянию данных
4) снимаем базу с поддержки, выгружаем cf
убиваем в менеджмент консоли базе данных в таблице config запись более 120Мб, делаем “загрузить конфигурацию” (не объединение) убиваем в менеджмент консоли базе данных в таблице config запись более 120Мб, делаем “загрузить конфигурацию” (не объединение)
1. Открыть конфигратор;
2. Снял конфигурацию с поддержки, ПРИ ЭТОМ КОНФИГУРАЦИЮ НЕ СОХРАНЯЛ!
3. Далее Сохранить конфигурацию в файл (не сохраняя измененной конфигурации);
4. В SQL для требуемой базы выполнил следующую команду:
DELETE FROM dbo.Config WHERE DataSize > 125829120
5. Загрузить сохраненную конфигурацию обратно.
можно попробовать и более радикальный шаг здесь:
удаляем (в менеджмент консоли) в базе данных таблицу “config”
D_rop TABLE [dbo].[Config]
5) делаем “загрузить конфигурацию” (не объединение) из cf
после этого проверяем, проблема уходит.
6) Ошибка :"Соединение с сервером баз данных разорвано администратором
Microsoft OLE DB Provider for SQL Server: Неопознанная ошибка
HRESULT=80004005"
Имеем : 1C 8.1.13.41 УПП 1.2.19.21 на MS SQL 2005 SP3 на Win2003 Server Enterprise на компе 4Gb физ. памяти (SQL настроен на Max Memory 2Gb)
Читайте также: