Database Versions:
SSMS: 17.9,
Oracle: 19.3
We are trying to establish a linked server connection to our production Oracle DB (hosted by another team) that uses SSL. The LS was created, however our test connection attempts always return this:
Cannot initialize the data source object of OLE DB provider "OraOLEDB.Oracle" for linked server "CDWRP201_TCPS". OLE DB provider "OraOLEDB.Oracle" for linked server "CDWRP201_TCPS" returned message "Error while trying to retrieve text for error ORA-28759". (Microsoft SQL Server, Error: 7303)
I read that this meant "failure to open file" and could be caused by insufficient wallet permissions so I gave our users full access to the files (not sure if this is recommended). I did the same for the ewallet, ORA files, and even their parent folders but still no success.
What's weird is that test connections work for our non-SSL connections, which use the same tnsnames.ora file. We have no problems connecting to the Oracle DB using tnsping and sqlplus as well.
I'm struggling with this because my experience with Oracle and SSMS linked servers are few to none and feel like I've hit a dead end. Any direction you can give will be very much appreciated. I'm happy to provide more details if needed.
Thank you very much.
You actually have TWO problems.
First, your call to oracle returned ORA-28795. AS others are focusing on, that results from a failure to open a wallet. However, rather than looking for permissions issues, I'd note the second error ...
The "Error while trying to retrieve text for error" indicates that your ORACLE_HOME (for the oracle client being used my msssql) is not correctly set. When the call received the ORA-28759, it needed to find the error message file to be able to properly report it. But with improper ORACLE_HOME it was unable to locate the message file.
And it very well might be the case that the invalid ORACLE_HOME is also the root cause of the ORA-28759. I've not much expderince with walllets, but it seems reasonable that it needs ORACLE_HOME to locate the wallet, just as it needs it to locate the message file ... and a bunch of other stuff. In any event, get ORACLE_HOME set correctly and you will get more informative diagnostics/error messages on your ORA-28795.
You said yourself that "The only variable that indicated Oracle was our PATH". You need to also set ORACLE_HOME. If your oracle PATH is 'C:\Oracle\x64\product\19.0.0\client_64\bin', then your ORACLE_HOME should be 'C:\Oracle\x64\product\19.0.0\client_64'
Related
I started in a large company as an IT consultant. One of my tasks is to manage an application that has a SQL database.
I have very limited knowledge of SSIDB and SQL Server Management Studio - but I am willing to learn.
The SQL database is updated with external data. This can be done by users directly in the application, but it also happens through a scheduled job. The job runs from SQL manager. The job has only two steps, one of which is to execute a dtsx package.
The dtsx package is set up retrieves data from an external FTP server and merges the data into the database. The job was made by my predecessor and has run flawlessly for a very long time.
Now we are in the situation where the FTP, supplying the data, has been changed.
I have therefore been inside the Connection managers and changed to the new FTP server.
Running the jobs however we still get the following error message:
Failed to configure a connection property that has the following path: \Package.Connections[FTPConnection].Propterties[ChunkSize]. An error occurred while setting the value of property “ChunkSize”. The error returned is 0x80020009 “The ValidateDates has been migrated. The package must be saved to retain migration changes.”
I have checked the Connection managers and the ChunkSize is unchanged from when the job was working correctly. ChunkSize is set to 1000, both in the Connection manager, but also in the dtsx package itself.
When I have searched for the problem, it is mentioned that it may have something to do with the connection to the FTP server. So I have checked the connection to the FTP server from the server where the SQL database is located - and there is a connection. In addition to this, I have also made sure that there is a firewall rule that allows traffic between the two servers. This is ensured across protocols and port 20-22
When the job itself is run, however, no traffic leaves the server. So I believe the problem is with the job itself.
Edit: after having done a validation of the package i have gotten the following.
Failed to configure a connection property that has the following path: \Package.Connections[FTPConnection].Propterties[ChunkSize]. An error occurred while setting the value of property “ChunkSize”. The error returned is 0x80020009 “The ValidateDates has been migrated. The package must be saved to retain migration changes.”.
: at Microsoft.SqlServer.IntegrationServices.Server.ISServerExec.ConnectionParametersManager.ConfigureProperties(Sting parameterName, object parameterValue)
at
Microsoft.SqlServer.IntegrationServices.Server.ISServerExec.ConnectionParametersManager.ConfigureProperties()
at
Microsoft.SqlServer.IntegrationServices.Server.ISServerExec.ProjectOperator.ValidatePackageWithReference(Int64 validationId, Int64 infold, Int64 projectId, String packageName, Int64 versionId, Nullable'1 referenceId, Project isserverProject, Boolean OfflineMode)
I hope my description is comprehensive enough - otherwise please do write follow-up questions.
ps english is not my first language. sorry if something didn't turn out too well.
The error is following:
The ODBC connection string is obviously wrong and not in the right format. But I don't understand where Access is getting it from! The correct and working connection string (string saved in the Access database via the Linked Table Manager) is below. It should be noted that my colleague is opening the compiled .accde file in Access Runtime and does not have Office installed on his computer. The data tables are in SQL Server. Another colleague, who does have Office installed (presumably) got it to open with no problem.
This is the proper connection string which is used in Linked Table Manager to link the tables to SQL Server:
"DRIVER=ODBC Driver 17 for SQL Server;SERVER=hgws19.win.hostgator.com;UID=*******;PWD=********;Trusted_Connection=No;APP=Microsoft Office;DATABASE=mypubid_usergamelog;"
What I can't understand is why this other string in the error message is being used instead of the correct one in Linked Table manager. Anyone have any ideas how to troubleshoot this?
I have created a SSIS package and I am trying to run it locally. We use package configurations that point to sql tables and a XML config file. The package ran successfully for about a week, even when deployed to a SQL Server Agent Job in our STAGE environment.
Now, the only way I can get the package to run is by not using the Package Configurations and choosing EncryptSensitivewithPassword. If I change the package to DontSaveSensitive, I continuously get the error below:
An OLE DB record is available. Source: "Microsoft SQL Server Native Client 11.0" Hresult: 0x80040E4D Description: "Login failed for user 'Test_User'.".
Error: 0xC020801C at AgentCompany, Lookup [37]: SSIS Error Code DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The AcquireConnection method call to the connection manager "Test" failed with error code 0xC0202009. There may be error messages posted before this with more information on why the AcquireConnection method call failed.
It is so strange that about a week ago, this package ran fine with the configurations and the DontSaveSensitive Option.
I have updated the config file to ensure that it is establishing the connection string to the appropriate database. I also test the connectivity on the connection managers and they all test successfully.
I also double checked the SQL Database where the user is trying to connect to ensure that it has permissions there and it does.
I am very confused. Please Help!
Updating dtsconfig file
Re-creating the connection managers
Making some DFT task DelayValidation to true
Changing the RunTime to 32 bit
EncrpytPasswordSensitive with package configs removed---This works but this is not the standard at my company and this is not how I developed and tested the package before
When you open/run a package, an OnInformation event is fired that says something like
The package is attempting to configure from the XML file "c:\ssisdata\so_56776576.dtsconfig".
When Visual Studio/SSDT opens/runs a package which says it uses configuration but for reasons, cannot get them, you should then see messages like
Warning loading so_56776576.dtsx: Failure importing configuration file: "c:\ssisdata\so_56776576.dtsconfig"
and
Warning loading so_56776576.dtsx: The configuration file "c:\ssisdata\so_56776576.dtsconfig" cannot be found. Check the directory and file name.
and
Warning loading so_56776576.dtsx: Failed to load at least one of the configuration entries for the package. Check configuration entries for "Configuration 1" and previous warnings to see descriptions of which configuration failed.
If someone has manually edited the config file and broken the XML, you'd see a warning like
Cannot load the XML configuration file. The XML configuration file may be malformed or not valid
The important thing to note with regard to configuration - if a configuration cannot be found, SSIS will continue along with the design time values. That is why it is crucial to check the warnings emitted when your package runs. If you are running manually, ensure that you have /rep ew specified so you report Errors and Warnings.
Guesses as to root cause
The package has the protection level of EncryptSensitiveWithUserKey which means the AD credentials of the package creator are used to hash things that might have sensitive information in them. I could be using AD authentication in my connection string and specify that the connection should be trusted but that entire block is still going to get encrypted against my Active Directory account. When you come along and attempt to maintain the package, it's not going to be able to decrypt the sensitive data as you are not me.
The two ways around that are to use a shared key (EncryptSensitiveWithPassword/EncryptPackageWithPassword) which is cumbersome to deal with plus it goes against the whole spirit of secrecy since everyone knows the secret. The other approach as you've identified is DontSaveSensitive and that's my go to for all of this.
The problem to be overcome is that with DontSaveSensitive is that every time you save, SSIS is going to wipe out any knowledge of user name and password from places that might be holding on to it - like a connection manager. The 2005/2008 strategy to hedge against this was to use Configuration or explicit overrides at run time to supply user name and password. My typical approach was to use configuration based on a table instead of XML as I was better at securing sensitive data in a table than I was mucking with ACL on the file system. The other challenge we had with multiple developers and file based configuration was that either everyone had to set their file systems up the same (and we developers are unique rainbow snowflakes so that's unlikely) or we need to use a network shared file which is great until someone adds their own values to it and breaks it or removes your changes or any of a host of other challenges.
I've performed multiple searches and read numerous pages and tried loads of different configurations and nothing seems to solve a nuisance problem we have. We have a SQL server (2008 R2 v10.50.4000) that has several linked servers to several different access databases on a different server. They are all set up using UNC paths and they work...for a time.
At some point, something happens and then we can no longer access the databases and the only way I have found to solve this is to restart the SQL server service, which obviously isn't ideal in a production environment. This is the exact error message we get when we try to access it:
OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "HIDDEN" returned message "The Microsoft Access database engine cannot open or write to the file '\servername\path01\path02\path03\databasename.mdb'. It is already opened exclusively by another user, or you need permission to view and write its data.".
Yet it works absolutely fine again if I restart the SQL Server service, so I know the settings are correct. I strongly suspect it has something to do with the Microsoft ACE driver because they all (the Access database linked servers) stop working at the same time - even though they all look at different files.
At this point I'm willing to try anything.
I am using msdeploy (version 2) to transfer a database from machine A to machine B.
On in the database on machine A there are some users that do not exist on machine B, thus the transfer (partially) fails with the message:
Error Code: ERROR_SQL_EXECUTION_FAILURE
More Information: An error occurred during execution of the database script.
The error occurred between the following lines of the script: "3" and "5".
The verbose log might have more information about the error.
The command started with the following: "CREATE USER [someDomain\someUser] FOR LOGIN [someDomain"
Windows NT user or group 'someDomain\someUser' not found.
Check the name again. http://go.microsoft.com/fwlink/?LinkId=178587
The database seems to be transfered, except for the user creation. Does anyone know what state the database is in after this failure?
Is there any way I can transfer the database without the users (or better without specific users) using msdeploy?
Web Deploy uses SMO (SQL Management Objects) to script out and apply the scripts for SQL databases, and exposes most of the SMO settings with the dbfullsql provider (so, most of these options: http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.management.smo.transfer_properties.aspx). If you want to skip the users due to this kind of login-not-exists or user-not-found error, you should be able to do this by adding the scripting option: copyAllUsers=false to the source of the sync. For example:
msdeploy.exe -verb:sync -source:dbfullsql="Data Source=.\SQLExpress;Initial Catalog=MySourceDb;User Id=localUser;Password=LocalPass",copyAllUsers=false -dest:dbfullsql="Data Source=RemoteSQLServer;Initial Catalog=MyDestDb;User Id=remoteUser;Password=RemotePass"
Incidentally, I am surprised you note the db appears to have been sync'd - I would expect this is not actually the case. If you have the permissions for it, Web Deploy will create the database if it did not already exist when it initially tries to make the connection, but your failure occurred very early in the script execution, and I believe Web Deploy dbfullsql syncs are transacted by default (the db creation is separate from the script execution and is not transacted). Thus the db may exist where it did not pre-sync, but I wouldn't expect the data to be present in it.