Как исправить ошибки ole db

I’m attempting to make a DTS package to transfer data between two databases on the same server and I’m getting the following errors. Iv read that the Multiple-step OLE DB operation generated error can occur when you are transferring between different database types and there is loss of precision, but this is not that case here. How do I examine the column meta data?

Error: 0xC0202009 at Data Flow Task,
piTech [183]: An OLE DB error has
occurred. Error code: 0x80040E21. An
OLE DB record is available. Source:
“Microsoft SQL Native Client”
Hresult: 0x80040E21 Description:
“Multiple-step OLE DB operation
generated errors. Check each OLE DB
status value, if available. No work
was done.”.

Error: 0xC0202025 at Data Flow Task,
piTech [183]: Cannot create an OLE DB
accessor. Verify that the column
metadata is valid.

Error: 0xC004701A at Data Flow Task,
DTS.Pipeline: component “piTech” (183)
failed the pre-execute phase and
returned error code 0xC0202025.

asked Sep 9, 2008 at 10:58

Dan's user avatar

Take a look at the fields’s proprieties (type, length, default value, etc.), they should be the same.

I had this problem with SQL Server 2008 R2 because the fields’s length are not equal.

answered Oct 1, 2011 at 11:02

Anïs El Haouéli's user avatar

4

This error is common when the source table contains a TEXT column and the target is anything other than a TEXT column. It can be a real time-eater if you have not encountered (or forgot!) this before.

Convert the text column to string and set the error condition on truncation to ignore. this will usually serve as a solution for this error.

bensiu's user avatar

bensiu

24.4k56 gold badges74 silver badges116 bronze badges

answered Oct 22, 2012 at 17:26

Oliphant's user avatar

OliphantOliphant

1111 silver badge2 bronze badges

0

This query should identify columns that are potential problems…

SELECT * 
FROM [source].INFORMATION_SCHEMA.COLUMNS src
    INNER JOIN [dest].INFORMATION_SCHEMA.COLUMNS dst 
        ON dst.COLUMN_NAME = src.COLUMN_NAME
WHERE dst.CHARACTER_MAXIMUM_LENGTH < src.CHARACTER_MAXIMUM_LENGTH 

Raj More's user avatar

Raj More

46.7k33 gold badges130 silver badges195 bronze badges

answered Sep 9, 2008 at 14:36

Michael Prewecki's user avatar

Michael PreweckiMichael Prewecki

2,0644 gold badges16 silver badges28 bronze badges

1

'-2147217887' message 'IDispatch error #3105' source 'Microsoft OLE DB Service Components' description 'Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available. No work was done.'."

This is what I was also facing. The problem came from the fact that I changed my SQLOLEDB.1 provider to SQLNCLI11 without mentioning the compatibility mode in the connection string.
When I set this DataTypeCompatibility=80; in the connection string, I got the problem solved.

answered Jun 21, 2017 at 9:11

Herve Mutombo's user avatar

Herve MutomboHerve Mutombo

1701 gold badge2 silver badges13 bronze badges

4

This issue will come mostly due to empty rows at the end of the file, remove those and run the job.

Petter Friberg's user avatar

answered Aug 4, 2017 at 10:46

jagadish ganaparthi's user avatar

For me the answer was that I was passing two parameters to and execute SQL task, but only using one. I was doing some testing and commented out a section of code using the second parameter. I neglected to remove the parameter mapping.

So ensure you are passing in the correct number of parameters in the parameter mapping if you are using the Execute SQL task.

answered Oct 9, 2018 at 17:36

Roi-Kyi Bryant's user avatar

1

You can use SELECT * FROM INFORMATION_SCHEMA.COLUMNS but I suspect you created the destination database from a script of the source database so it is very likely that they columns will be the same.

Some comparisons might bring something up though.

These sorts of errors sometimes come from trying to insert too much data into varchar columns too.

Raj More's user avatar

Raj More

46.7k33 gold badges130 silver badges195 bronze badges

answered Sep 9, 2008 at 11:04

Michael Prewecki's user avatar

Michael PreweckiMichael Prewecki

2,0644 gold badges16 silver badges28 bronze badges

I had a similar issue when i was transferring data from an old database to a new database, I got the error above. I then ran the following script

SELECT * FROM [source].INFORMATION_SCHEMA.COLUMNS src INNER JOIN [dest].INFORMATION_SCHEMA.COLUMNS dst ON dst.COLUMN_NAME = src.COLUMN_NAME WHERE dst.CHARACTER_MAXIMUM_LENGTH < src.CHARACTER_MAXIMUM_LENGTH

and found that my columns where slightly different in terms of character sizes etc.
I then tried to alter the table to the new table structure which did not work. I then transferred the data from the old database into Excel and imported the data from excel to the new DB which worked 100%.

answered Apr 13, 2010 at 9:23

DON's user avatar

Also check if the script has no batch seperator commands (remove the ‘GO’ statements on a single line).

answered Jun 16, 2017 at 12:04

In my case, the problem was setting the variable of the Execute SQL Task, in parameters mapping the parameter name, (in OLEDB must be the position of the parameter that you call in the stored procedure), I had 1, but the first parameter starts in 0, so I changed it and voilá!

answered Jan 15, 2020 at 11:29

Artemination's user avatar

ArteminationArtemination

7032 gold badges10 silver badges29 bronze badges

check if you have written GO statement in your query. If it’s there then try to remove it.

drop table if exists Employee
GO

If should be only

drop table if exists Employee

answered Apr 26, 2022 at 11:27

Ravi's user avatar

This error will also occur when trying to do an insert and a field is coded not null and nulls are trying to be inserted.

answered Jul 25, 2013 at 20:32

polrbar5's user avatar

I hade this error when transfering a csv to mssql
I converted the columns to DT_NTEXT and some columns on mssql where set to nvarchar(255).

setting them to nvarchar(max) resolved it.

answered Nov 7, 2015 at 0:11

normalo's user avatar

Introduction:

Sometimes while refreshing our dataset in PowerBI or importing new data from existing sources we may encounter OLE DB or ODBC errors as shown in the image below. This might be due to caching issues. To solve this follow the steps:

Go to File tab on the ribbon in PowerBI Desktop , then click on About and check the PowerBI version, make sure it is the latest version if not update PowerBI.

If PowerBI version is latest, click on the dropdown arrow below the Transform Data button.

Click on Data source settings

Click on Global Permissions

Select the Data Source and click on Clear Permissions and click on close.

  • Click on close and again select the data source as new and enter the credentials.
  • This time the dataset would be loaded without errors.
  • Hope this article helped

Related posts:

Share Story :

SEARCH BLOGS :

This guide is designed to give you all of the resources needed to troubleshoot and resolve OLE DB/ODBC exception errors. OLE DB/ODBC is a type of protocol used for connecting to a various data sources such as Microsoft SQL Server and Oracle Database. If a OLE DB/ODBC Exception Error (HRESULT 0x80040E4E) is encountered during this application development process, it can be a both time-consuming and frustrating process to try to fix. Follow the instructions below to quickly and effectively troubleshoot and resolve the Exception Errors.

Overview of OLE DB/ODBC Exception Error

OLE DB/ODBC Exception Error is an error that occurs in the ODBC layer or the OLE DB layer of the Microsoft Data Link (MDL) layer’s stack. It typically appears as HRESULT 0x80040E4E and can be associated with a variety of errors such as:

  • Tried to fetch data from an invalid source
  • Incorrect connection information
  • Invalid or uninitialized parameter values in a query
  • Data conversion errors
  • Timeouts
  • Network issues

In order to properly troubleshoot and resolve the issue, you must first understand the basic components of OLE DB/ODBC, what can cause the Exception Error, and the best ways to identify the root cause.

Troubleshooting & Resolving OLE DB/ODBC Exception Error

1. Gathering Information

Before you can troubleshoot any further, you must first gather information in order to begin to understand what may be causing the Exception Error. Gather the necessary information such as:

  • The application being used
  • The type of database or data source driver being used
  • The type of connection string being used
  • The model of server or environment being used
  • Any recent changes made to the environment
  • The version of the ODBC driver being used

This information can be used to begin to get a better understanding of the environment and the potential causes of the Exception Error.

2. Identifying Potential Causes

Once you have gathered the necessary information, it is time to identify any possible causes of the Exception Error. Some common causes of the Exception Error include:

  • A problem with the ODBC driver being used
  • Invalid connection information
  • Corrupt data being passed to the driver
  • A network issue with any communication between the data source and application

It is important to identify the root cause of the Exception Error in order to properly resolve it.

3. Resolving the Exception Error

Once you have identified the cause of the Exception Error, you can begin to troubleshoot and resolve the issue. Depending on the cause, some common solutions may include:

  • Updating or reinstalling the ODBC driver
  • Verifying the connection information
  • Restarting the server
  • Utilizing a network monitoring tool to check for any network issues
  • Upgrading the version of the server or ODBC Driver
  • Checking for any corrupt data

FAQ

Q1. What is OLE DB/ODBC Exception Error?

A1. OLE DB/ODBC Exception Error is an error that occurs in the ODBC layer or the OLE DB layer of the Microsoft Data Link (MDL) layer’s stack. It typically appears as HRESULT 0x80040E4E and can be associated with a variety of errors such as:

  • Tried to fetch data from an invalid source
  • Incorrect connection information
  • Invalid or uninitialized parameter values in a query
  • Data conversion errors
  • Timeouts
  • Network issues

Q2. What are the steps for troubleshooting and resolving an OLE DB/ODBC Exception Error?

A2. The steps for troubleshooting and resolving an OLE DB/ODBC Exception Error include:

  1. Gathering information
  2. Identifying potential causes
  3. Resolving the Exception Error

Q3. What are some common causes of the Exception Error?

A3. Some common causes of the Exception Error include:

  • A problem with the ODBC driver being used
  • Invalid connection information
  • Corrupt data being passed to the driver
  • A network issue with any communication between the data source and application

Q4. What are some common solutions for resolving the Exception Error?

A4. Some common solutions for resolving the Exception Error include:

  • Updating or reinstalling the ODBC driver
  • Verifying the connection information
  • Restarting the server
  • Utilizing a network monitoring tool to check for any network issues
  • Upgrading the version of the server or ODBC Driver
  • Checking for any corrupt data

Q5. What type of protocol is OLE DB/ODBC?

A5. OLE DB/ODBC is a type of protocol used for connecting to a variety of data sources such as Microsoft SQL Server and Oracle Database.

  1. Microsoft OLE DB/ODBC Driver Download: https://www.microsoft.com/en-us/download/details.aspx?id=20098

Содержание

  1. KB3008000-FIX: ошибка при использовании поставщика OLE DB для ядра СУБД Office 15,0 в качестве источника данных в SSMS 2012 или SSMS 2014
  2. Проблемы
  3. Причина
  4. Решение
  5. Накопительное обновление 4 для SQL Server 2012 с пакетом обновления 2 (SP2) /en-us/help/3007556
  6. Накопительное обновление 5 для SQL Server 2014 /en-us/help/3011055
  7. Накопительное обновление 13 для SQL Server 2012 с пакетом обновления 1 (SP1) /en-us/help/3002044
  8. Сообщение об ошибке поставщику OLE DB SQLOLEDB не удалось запустить распределенную транзакцию
  9. Симптомы
  10. Причина
  11. Обходной путь
  12. Получить 7399 и 7300 сообщений об ошибках при обращении к связанному серверу
  13. Проблемы
  14. Причина
  15. Обходное решение
  16. Ошибка СУБД Microsoft OLE DB Provider for SQL базы 1С Предприятие 8.2
  17. Как исправить: поставщик Microsoft OLE DB для SQL Server Ошибка 80040e4d
  18. Обновление за январь 2023 года:
  19. Проверка источников данных ODBC

KB3008000-FIX: ошибка при использовании поставщика OLE DB для ядра СУБД Office 15,0 в качестве источника данных в SSMS 2012 или SSMS 2014

Проблемы

Предположим, что вы импортируете базу данных Access в базу данных Microsoft SQL Server с помощью мастера импорта и экспорта в SQL Server 2012 Management Studio (SSMS 2012) или SSMS 2014. При использовании поставщика OLE DB ядра СУБД Microsoft Office 15,0 для доступа к источнику данных появляется следующее сообщение об ошибке:

Не удалось присоединить исходный компонент. Ошибка 0xc0202009: Source-XXXX [1]: код ошибки служб SSIS DTS_E_OLEDBERROR. Произошла ошибка OLE DB. Код ошибки: 0x80040E37. Ошибка 0xc02020e8: Source-XXXX [1]: не удалось открыть набор строк для «XXXX». Убедитесь, что объект существует в базе данных.

Причина

Проблема возникает из-за того, что поставщик OLE DB для ядра СУБД Microsoft Office 15,0 не поддерживается. При использовании в качестве источника данных связанное имя таблицы не найдено в базе данных Access.

Решение

Эта проблема впервые устранена в следующем накопительном обновлении SQL Server.

Накопительное обновление 4 для SQL Server 2012 с пакетом обновления 2 (SP2) /en-us/help/3007556

Накопительное обновление 5 для SQL Server 2014 /en-us/help/3011055

Накопительное обновление 13 для SQL Server 2012 с пакетом обновления 1 (SP1) /en-us/help/3002044

Все новые накопительные обновления для SQL Server содержат все исправления и все исправления для системы безопасности, которые были включены в предыдущий накопительный пакет обновления. Ознакомьтесь с самыми последними накопительными обновлениями для SQL Server.

Корпорация Майкрософт подтверждает наличие этой проблемы в своих продуктах, которые перечислены в разделе «Применяется к».

Источник

Сообщение об ошибке поставщику OLE DB SQLOLEDB не удалось запустить распределенную транзакцию

Эта статья поможет вам обойти проблему, из-за того, что сообщение об ошибке поставщика OLE DB SQLOLEDB не удалось запустить распределенную транзакцию.

Оригинальная версия продукта: SQL Server
Исходный номер базы знаний: 816701

Симптомы

При попытке использовать microsoft SQL Server для запуска распределенной транзакции между связанными серверами под управлением Windows Server может появиться следующее сообщение об ошибке:

Поставщик OLE DB SQLOLEDB не смог начать распределенную транзакцию

На компьютере поставщика OLE DB может появиться следующее сообщение:

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

Причина

Это происходит, если служба координатора распределенных транзакций (DTS) отключена или если доступ к DTC сети отключен. По умолчанию доступ к сетевому DTC отключен в Windows Server.

Обходной путь

Чтобы обойти это поведение, установите сетевой доступ DTC на обоих серверах:

  1. Нажмите кнопку Пуск и выберите Панель управления.
  2. Щелкните Добавить или удалить программы, а затем — Добавить и удалить компоненты Windows.
  3. В поле Компоненты щелкните Сервер приложений, а затем — Сведения.
  4. Установите флажок Включить доступ к DTC в сети , а затем нажмите кнопку ОК.
  5. Нажмите кнопку Далее, а затем следуйте инструкциям, которые отображаются на экране, чтобы завершить процесс установки.
  6. Остановите и перезапустите службу координатора распределенных транзакций.
  7. Остановите и перезапустите все службы Resource Manager, участвующие в распределенной транзакции (например, Microsoft SQL Server или Microsoft Message Queue Server).

Источник

Получить 7399 и 7300 сообщений об ошибках при обращении к связанному серверу

Проблемы

Рассмотрим следующий сценарий.

У вас есть экземпляр SQL Server, который установлен на компьютере под управлением Windows Vista или более поздней версии операционной системы.

На этом экземпляре SQL Server настройте связанный сервер к источнику данных с помощью поставщика OLEDB для источника данных OLEDB.

Поставщик OLE DB должен быть создан вне процесса SQL Server. Обычно это значение по умолчанию для большинства поставщиков OLEDB, кроме собственного клиента SQL. Это может управляться параметр Allow inprocess , которое может быть установлено с помощью свойства поставщика в Studio на доступ к данным SQL Server.

Безопасность связанный сервер настроен на использование быть сделаны с использованием текущего контекста безопасности имени входа параметр.

В этом случае при непривилегированные пользователи журналов в SQL Server экземпляра с использованием проверки подлинности Windows и попытке доступа к связанному серверу, они могут возникнуть сообщение об ошибке, подобное приведенному ниже:

Сообщение 7399, уровень 16, состояние 1, поставщика OLE DB строка 1Процесс для связанного сервера сообщил об ошибке. Поставщик не предоставил никакой информации об ошибке. Сообщение 7330, уровень 16, состояние 2, строка 1Cannot получить строку от поставщика OLE DB для связанного сервера.

Примечание: В данном контексте непривилегированного пользователя является стандартный пользователь не принадлежит к группе привилегированный доступ на уровне Windows (например: Администраторы)

Причина

При запуске средства доступа OLE DB из процесса библиотеки OLE-DB интерфейс удаленного взаимодействия (msdaps.dll) обеспечивает взаимодействие между прокси-процесс стороны, в которой находится клиент OLE DB и заглушки стороны процесса, в котором находится поставщик OLE DB. В текущей реализации. OLE DB удаленного взаимодействия использует именованный файл сопоставления объектов для передачи данных набора строк OLE DB. В системах под управлением Vista или более поздней версии операционной системы сторонах прокси и заглушка выполняются в разных сеансах из-за изоляции сеанса 0 и таким образом OLE DB удаленного взаимодействия необходимо использовать глобальный для связи заглушки прокси-сервера в этих системах. Тем не менее, поскольку учетная запись пользователя не имеет достаточные права для создания объекта сопоставления глобальный файл конфигурации указанного связанного сервера, связь заглушки прокси-сервера не может быть начат в описанных выше сообщений об ошибках части этой статьи.

Обходное решение

Можно обхода проблемы с помощью одного из следующих методов:1 решение: настроить поставщик OLEDB для запуска в процессе. Примечание: Нельзя использовать этот метод обхода уязвимости для поставщиков OLEDB, основанных на .net версии, более ранней, чем 4.0. Метод обхода 2: назначить пользователей право «Создание глобальных объектов». Чтобы сделать это, выполните следующие действия.

Нажмите кнопку Пуск, выберите пункт Администрированиеи щелкните Локальная политика безопасности.

Разверните узел Локальные политикии щелкните Назначение прав пользователя.

В правой области дважды щелкните Создание глобальных объектов.

В диалоговом окне Параметр локальной политики безопасности нажмите кнопку Добавить.

В диалоговом окне Выбор: пользователи или группы нажмите кнопку учетные записи пользователей, которые требуется добавить, нажмите кнопку Добавитьи нажмите кнопку ОК.

Нажмите кнопку ОК.

Состояние: Корпорация Майкрософт в настоящее время работает на устранение этой проблемы в будущих версиях продукта.

Источник

Ошибка СУБД Microsoft OLE DB Provider for SQL базы 1С Предприятие 8.2

Как-то случилась у нас на предприятии «беда». Беда эта была связана с базой данных 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

Ошибка хоть и не была критичной, но не давала работать людям. Были предприняты попытки связаться с интегратором, чтобы он хоть чем-то помог. В основном поступали предложения о том, чтобы загрузить Конфигуратор и попытаться Выгрузить/Загрузить базу в .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

После этого, можно расслабиться не на долго. Все должно работать. Табличные части восстановлены, запросы которые выполняют пользователи при обращении к базе данных проходят корректно, и клиент не ругается на ошибку СУБД. Надеюсь моя запись будет полезна кому-то.

Источник

Как исправить: поставщик Microsoft OLE DB для SQL Server Ошибка 80040e4d

Please enable JavaScript

Последнее обновление 18 декабря 2018 г.

Обновлено 2023 января: перестаньте получать сообщения об ошибках и замедлите работу вашей системы с помощью нашего инструмента оптимизации. Получить сейчас в эту ссылку

  1. Скачайте и установите инструмент для ремонта здесь.
  2. Пусть он просканирует ваш компьютер.
  3. Затем инструмент почини свой компьютер.

При попытке использовать имя источника данных ODBC (DSN) для открытия соединения объектов данных ActiveX (ADO) с базой данных SQL Server со страницы Active Server Pages (ASP) вы можете получить следующее сообщение об ошибке:

Поставщик Microsoft OLE DB для драйверов ODBC (0x80040E4D)
[Microsoft] [Драйвер ODBC SQL Server] [SQL Server] Ошибка входа для пользователя ‘(null)’. Причина: не связано с доверенным подключением к SQL Server.

Каковы причины этой ошибки?

1. Вы подключились к неверному серверу MSSQL.

2 Имя пользователя и пароль базы данных могут быть недействительными.

Обновление за январь 2023 года:

Теперь вы можете предотвратить проблемы с ПК с помощью этого инструмента, например, защитить вас от потери файлов и вредоносных программ. Кроме того, это отличный способ оптимизировать ваш компьютер для достижения максимальной производительности. Программа с легкостью исправляет типичные ошибки, которые могут возникнуть в системах Windows — нет необходимости часами искать и устранять неполадки, если у вас под рукой есть идеальное решение:

  • Шаг 1: Скачать PC Repair & Optimizer Tool (Windows 10, 8, 7, XP, Vista — Microsoft Gold Certified).
  • Шаг 2: Нажмите «Начать сканирование”, Чтобы найти проблемы реестра Windows, которые могут вызывать проблемы с ПК.
  • Шаг 3: Нажмите «Починить все», Чтобы исправить все проблемы.

Проверка источников данных ODBC

Необходимо проверить источники данных ODBC, используемые WhatsUp Gold для доступа к базе данных, а затем перенести изменения в утилиту конфигурации базы данных WhatsUp Gold. Для этого необходимо выполнить следующие шаги:

ODBC соединение

  1. В меню «Пуск» Windows выберите: Для 32-разрядной операционной системы Windows: Панель управления> Администрирование> Источники данных, затем вкладка Системный DSN — или — для 64-разрядной операционной системы Windows: выберите «Выполнить» и введите (без кавычки) «c: Windows SysWOW64 odbcad32.exe»; затем выберите вкладку Системный DSN в диалоговом окне Администратор источника данных ODBC.
  2. Выберите DSN «WhatsUp», затем нажмите кнопку «Настроить», и появится мастер настройки.
  3. Убедитесь, что назначено имя «WhatsUp» (или «NetFlow», если вы проверяете NetFlow DSN) и что поле «Сервер» назначено правильно, т.е. >.
  4. Во втором диалоговом окне убедитесь, что опция «С Проверка подлинности SQL Server с идентификатором для входа и паролем, введенным пользователем ». Введите имя пользователя SQL в поле Логин.
  5. В поле «Пароль» введите пароль пользователя SQL (по умолчанию для WUG будет «пользователь» и пароль для «WhatsUp_Gold»), затем нажмите «Далее».
  6. В третьем диалоговом окне убедитесь, что выбран параметр «Изменить базу данных по умолчанию» и что база данных WhatsUp (или NetFlow, если она настроена для NetFlow) отображается в раскрывающемся меню, затем нажмите «Далее».
  7. Продолжайте нажимать «Далее», пока не дойдете до последнего диалогового окна, затем нажмите «Готово».
  8. Откроется диалоговое окно ODBC установки Microsoft SQL Server. Вы можете нажать кнопку «Проверить источник данных» или «ОК», чтобы проверить конфигурацию.
  9. Повторите шаги с b по f для DSN «NetFlow» и «iDroneService».

Проверьте, есть ли у учетной записи UISR анонимный доступ.

  1. Войдите в базу знаний Сервера приложений как пользователь с правами администратора.
  2. Щелкните правой кнопкой мыши значок «Мой компьютер» и выберите «Управление» в меню.
  3. В окне «Управление компьютером» разверните «Службы и приложения»> «Диспетчер информационных служб Интернета» (IIS)> «Сайты».
  4. Щелкните правой кнопкой мыши на ClientPortal и выберите «Свойства» в меню.
  5. На вкладке «Безопасность каталога» в разделе «Проверка подлинности и контроль доступа» выберите «Изменить».
  6. Убедитесь, что опция «Включить анонимный доступ» включена для имени пользователя UISR.
  7. Нажмите кнопку ОК, чтобы сохранить все изменения.
  8. Нажмите кнопку ОК, чтобы закрыть свойства ClientPortal.
  9. Повторите шаги 4-8 для портала клиентов.

После устранения всех проблем, связанных с этими тремя причинами, пользователи больше не должны видеть сообщение об ошибке при подключении к базе знаний панели управления администратора.

Совет экспертов: Этот инструмент восстановления сканирует репозитории и заменяет поврежденные или отсутствующие файлы, если ни один из этих методов не сработал. Это хорошо работает в большинстве случаев, когда проблема связана с повреждением системы. Этот инструмент также оптимизирует вашу систему, чтобы максимизировать производительность. Его можно скачать по Щелчок Здесь

CCNA, веб-разработчик, ПК для устранения неполадок

Я компьютерный энтузиаст и практикующий ИТ-специалист. У меня за плечами многолетний опыт работы в области компьютерного программирования, устранения неисправностей и ремонта оборудования. Я специализируюсь на веб-разработке и дизайне баз данных. У меня также есть сертификат CCNA для проектирования сетей и устранения неполадок.

Источник

Ошибка возникла на Windows Server 2008 R2 при попытке входа в ИБ 1С SQL. При этом на сервере зарегистрированы несколько баз: в одни пользователям удается войти, в другие — нет.

Со стороны клиентского приложения выводится сообщение «В данный момент вход в приложение невозможен, попробуйте войти позже».

Полный текст ошибки при выборе «Показать подробности…»: «Ошибка СУБД: Компоненты OLE DB провайдера не найдены CoCreateInstance: -2147023878(0x800703FA): Попытка произвести недопустимую операцию над параметром реестра, отмеченным для удаления».

Вид ошибки в клиентском приложении 1С

Причина

Сообщение может быть выдано, если сервер 1С:Предприятия не смог создать COM-объект OLE DB Provider for Microsoft SQL Server. Другие возможные причины: нехватка оперативной памяти, ошибки ОЗУ или сбой службы/кэша 1С.

Варианты решений

1. Если 1С запускается на терминальном сервере, завершите полностью сеансы пользователя и выполните повторный вход.

2. Запустите командную строку от имени администратора и выполните проверки диска(-ов) на ошибки и целостность системных файлов.

chkdsk %SystemDrive%
sfc /scannow

3. Проверьте свободное место на диске(-ах). Сделайте очистку при необходимости.

4. Выполните очистку локального/серверного кэша 1С.

5. Убедитесь, что у пользователя, от имени которого запускается «Агент сервера 1С:Предприятия», есть права на каталог, содержащий компоненту OLE DB провайдера и на файлы в этом каталоге.

  • Найдите в системном реестре ветку
    HKEY_CLASSES_ROOTCLSID{0C7FF16C-38E3-11d0-97AB-00C04FC2AD98}InprocServer32
    и посмотрите путь до файла sqloledb.dll в параметре «(По умолчанию)»
    Например: «%CommonProgramFiles%SystemOle DBsqloledb.dll»
  • Проверьте, что файл библиотеки sqloledb.dll находится в папке. Каталог с файлом должен быть доступен пользователю USR1CV8 (Учетная запись для Сервера 1С:Предприятия 8).
  • Переустановите Microsoft Data Access Components (MDAC).

6. Перезагрузите службы 1С и SQL. Последовательно остановите Агент 1С, службы SQL Server. Далее запустите SQL Server > Агент 1C.

7. Для проверки перезапустите «Агент сервера 1С:Предприятия» от имени системной учетной записи. Вход от имени: Локальная система.

8. Через оснастку «Администрирование серверов 1С Предприятия» удалите запись о сбойной ИБ в режиме «Оставить без изменений». Зарегистрируйте ИБ на сервере 1С повторно.

9. Перезагрузите сервер.

10. Выполните восстановление 1С в панели «Программы и компоненты» или переустановите платформу и сервер 1С.

✅ Надеемся, что действия из списка смогут вам помочь в исправлении этой ошибки. Поделитесь, что сработало в вашем случае — в комментариях.

__________
Если не получается или требуется дополнительная поддержка, наши программисты 1С готовы помочь → +7-911-500-10-11

Добавить комментарий