Azure SQL server import export responds with Error SQL72014: .Net SqlClie
Not able to see full stacktrace
Demo logs are as below
Additional details
Could not import package.
Warning SQL72012: The object [information_9] exists in the target, but it will not be dropped even though you selected the 'Generate drop statements for objects that are in the target database but that are not in the source' check box.
Warning SQL72012: The object [stacktrace] exists in the target, but it will not be dropped even though you selected the 'Generate drop statements for objects that are in the target database but that are not in the source' check box.
Error SQL72014: .Net SqlClie
Error logs are incomplete. So, I am not able to identify MSG message number for it.
Please suggest possible solutions.
The error SQL72014 is requesting to enable contained database authentication on the SQL Server instance.
In order to restore a contained database coming from Azure SQL Database into on-premise SQL Server instance the "contained database authentication" property must be enabled.
Solution:
To enable this property please try the below script:
sp_configure 'contained database authentication', 1;
GO
RECONFIGURE;
GO
I have cloned our Microsoft SQL to a new server. The server contains a few databases and "SQL Server Agent" jobs that run on a scheduled basis. I have tried changing all existing references to this new server name and use accounts on this new server. However I am still getting the following error in my error log and my jobs fails to run (btw, this is through Microsoft SQL Management Studio),
[298] SQLServer Error: 15404, Could not obtain information about Windows NT group/user 'DOMAIN\user_account', error code 0x534. [SQLSTATE 42000] (ConnIsLoginSysAdmin)
I've got a couple of Maintenance Plans which are pointing to the old server. For some unknown reason I can't edit the existing connection and I can't delete it. I can add a new one but the other connection can not be removed.
I need to know where I need to change for this error to go away and the jobs start running.
This may be because SQL has the wrong server name in Master. Here is another article on the subject.
SQL Server Central Article
In order to fix this, run a search on Master with the following code:
use master
select SERVERPROPERTY('servername')
select ##SERVERNAME
select SERVERPROPERTY('machinename')
go
If you see the old server name in the list you will have to drop the server and add the new one
use master
exec sp_dropserver "OldServerNmae"
go
use master
exec sp_addserver "NewServerName","local"
go
Local SQL Server version: 2017 (v14.0.1000.169)
Remote Azure SQL server version: 12.0.2000.8
SQL Server Management Studio version: 14.0.17289.0 (v17.9.1)
Steps taken:
Export database from Azure SQL server using Tasks -> Export Data-tier Application (I have also tried excluding the Hangfire Schema)
Import database into Local SQL server using Tasks -> Import Data-tier Application
Getting this error:
Could not import package.
Warning SQL72012: The object [mydatabase20181127deploy_Data] exists in the target, but it will not be dropped even though you selected the 'Generate drop statements for objects that are in the target database but that are not in the source' check box.
Warning SQL72012: The object [mydatabase20181127deploy_Log] exists in the target, but it will not be dropped even though you selected the 'Generate drop statements for objects that are in the target database but that are not in the source' check box.
Error SQL72014: SQL Execution error: A fatal error occurred. The variable HangFireSchema could not be found.
Error SQL72045: Script execution error. The executed script:
CREATE SCHEMA [$(HangFireSchema)]
AUTHORIZATION [MyDatabase];
Error SQL72014: SQL Execution error: A fatal error occurred. Incorrect syntax was encountered while CREATE SCHEMA [$(HangFireSchema)] was being parsed.
Error SQL72045: Script execution error. The executed script:
CREATE SCHEMA [$(HangFireSchema)]
AUTHORIZATION [MyDatabase];
(Microsoft.SqlServer.Dac)
Currently moving a database to Azure SQL. I've generated a script to import the database. In SQL management studio, I've connected to the cloud database as the server admin. I try to run the script - though I get multiple errors such as -
ODBC error: State: 28000: Error: 18456 Message:'[Microsoft][ODBC Driver 13 for SQL Server][SQL Server]Login failed for user '##MS_InstanceCertificate##'.'.
Msg 5069, Level 16, State 3, Line 11
and
Looking around I found;
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-manage-logins
I went through the steps to create a user and add to the role dbmanager.
I'm still getting the same errors when running the database import script.
As a heads up, I've run this script logged in as the server admin and as the user created by the server admin.
Any help is greatly appreciated.
The error message is a bit misleading, it hasn't (necessarily) something to do with certificates. In general, this error message says that connecting to the database with a certain user failed. So check...
if the user exists
if the username is spelled correctly
if the database you connect to exists
if the database name is spelled correctly
I am trying to run openrowset from MS SQL Server on an Oracle server.
When i execute the following command:
select * from
OPENROWSET('OraOLEDB.Oracle','srv';'user';'pass',
'select * from table')
the following error occurs
Msg 7302, Level 16, State 1, Line 1
Cannot create an instance of OLE DB provider "OraOLEDB.Oracle" for linked server "(null)".
Can anyone tell me how I can use openrowset with OraOLEDB.Oracle?
I am using 64 bit version of MS SQL Server and Oracle OLEDB driver.
Edit
I have tried this on two machines running Windows 7 x64 & Windows Server 2008 x64 with MS SQL Server 2008 x64. Both showed the same error message.
In SQL Server Enterprise Manager, open \Server Objects\Linked Servers\Providers, right click on the OraOLEDB.Oracle provider, select properties and check the "Allow inprocess" option. Recreate your linked server and test again.
You can also execute the following query if you don't have access to SQL Server Management Studio :
EXEC master.dbo.sp_MSset_oledb_prop N'OraOLEDB.Oracle', N'AllowInProcess', 1
Ran into this issue where the linked server would work for users who were local admins on the server, but not for anyone else. After many hours of messing around, I managed to fix the problem using the following steps:
Run (CTRL + R) “dcomcnfg”. Navigate to “Component Services -> Computers -> My Computer -> DCOM Config”.
Open the properties page of “MSDAINITIALIZE”.
Copy the “Application ID” on the properties page.
Close out of “dcomcnfg”.
Run “regedit”. Navigate to “HKEY_CLASSES_ROOT\AppID{???}” with the ??? representing the application ID you copied in step #3.
Right click the “{???}” folder and select “Permissions”
Add the local administrators group to the permissions, grant them full control.
Close out of “regedit”.
Reboot the server.
Run “dcomconfig”. Navigate to “Component Services -> Computers -> My Computer -> DCOM Config”.
Open the properties page of “MSDAINITIALIZE”.
On the “Security” tab, select “Customize” under “Launch and Activation Permissions”, then click the “Edit” button.
Add “Authenticated Users” and grant them all 4 launch and activation permissions.
Close out of “dcomcnfg”.
Find the Oracle install root directory. “E:\Oracle” in my case.
Edit the security properties of the Oracle root directory. Add “Authenticated Users” and grant them “Read & Execute”, “List folder contents” and “Read” permissions. Apply the new permissions.
Click the “Advanced Permissions” button, then click “Change Permissions”. Select “Replace all child object permissions with inheritable permissions from this object”. Apply the new permissions.
Find the “OraOLEDB.Oracle” provider in SQL Server. Make sure the “Allow Inprocess” parameter is checked.
Reboot the server.
When connecting to SQL Server with Windows Authentication (as opposed to a local SQL Server account), attempting to use a linked server may result in the error message:
Cannot create an instance of OLE DB provider "(OLEDB provider name)"...
The most direct answer to this problem is provided by Microsoft KB 2647989, because "Security settings for the MSDAINITIALIZE DCOM class are incorrect."
The solution is to fix the security settings for MSDAINITIALIZE. In Windows Vista and later, the class is owned by TrustedInstaller, so the ownership of MSDAINITIALIZE must be changed before the security can be adjusted. The KB above has detailed instructions for doing so.
This MSDN blog post describes the reason:
MSDAINITIALIZE is a COM class that is provided by OLE DB. This class can parse OLE DB connection strings and load/initialize the provider based on property values in the connection string. MSDAINITILIAZE is initiated by users connected to SQL Server. If Windows Authentication is used to connect to SQL Server, then the provider is initialized under the logged in user account. If the logged in user is a SQL login, then provider is initialized under SQL Server service account. Based on the type of login used, permissions on MSDAINITIALIZE have to be provided accordingly.
The issue dates back at least to SQL Server 2000; KB 280106 from Microsoft describes the error (see "Message 3") and has the suggested fix of setting the In Process flag for the OLEDB provider.
While setting In Process can solve the immediate problem, it may not be what you want. According to Microsoft,
Instantiating the provider outside the SQL Server process protects the SQL Server process
from errors in the provider. When the provider is instantiated outside the SQL Server process,
updates or inserts referencing long columns (text, ntext, or image) are not allowed.
-- Linked Server Properties doc for SQL Server 2008 R2.
The better answer is to go with the Microsoft guidance and adjust the MSDAINITIALIZE security.
For error 7302 in particular, I discovered, in my registry, when looking for OraOLEDB.Oracle that the InprocServer32 location was wrong.
If that's the case, or you can't find that string in the registry, then you'll have to install or re-register the component.
I had to delete the key from the GUID level, and then find the ProgID (OraOLEDB.Oracle) key, and delete that too. (The ProgID links to the CLSID as a pair).
Then I re-registered OraOLEDB.Oracle by calling regsvr32.exe on ORAOLEDB*.dll.
Just re-registering alone didn't solve the problem, I had to delete the registry keys to make it point to the correct location. Alternatively, hack the InprocServer32 location.
Now I have error 7308, about single threaded apartments; rolling on!
Received this same error on SQL Server 2017 trying to link to Oracle 12c. We were able to use Oracle's SQL Developer to connect to the source database, but the linked server kept throwing the 7302 error.
In the end, we stopped all SQL Services, then re-installed the ODAC components. Started the SQL Services back up and voila!
Aside from other great responses, I just had to give NTFS permissions to the Oracle installation folder.
(I gave read access)
Similar situation for following configuration:
Windows Server 2012 R2 Standard
MS SQL server 2008 (tested also SQL 2012)
Oracle 10g client (OracleDB v8.1.7)
MSDAORA provider
Error ID: 7302
My solution:
Install 32bit MS SQL Server (64bit MSDAORA doesn't exist)
Install 32bit Oracle 10g 10.2.0.5 patch (set W7 compatibility on setup.exe)
Restart SQL services
Check Allow in process in MSDAORA provider
Test linked oracle server connection
Just enable option "Allow in process" on the properties of the OraOLEDB.oracle provider as below
[open server objects > Linked Severs > providers] 1 [right click on
OraOLEDB.oracle > properties ] 2 then choose optaion "Allow in
process" and click ok