I have a SSIS package on sql server 2012.
It utilizes an easysoft odbc connection to access and optima attendance controller. In my project, I have
Run64BitRuntime is false. My SQL Agent Job is also set for 32 bit run time.
I use and SSIS proxy account and it is an admin account.
I have another package running on the same server using a different odbc provider, timebersoft, but it runs without issue.
If you need more details please let me know what you need to know.
The following errors only occur when the package is exacuted by a sql server agent job.
Data Flow TAsk: Error: ODBC source failed validation and returned error code 0x80004005
attnd: Error: There was an error trying to establish and Open Database Connectivity (ODBC) connection with the database server.
Data Flow Task: Error: The AquireConnection method call to the connection manager Attnd failed with error code 0xC0014009.
I have attempted to create a hello world version and every time the only thing to cause it to crash is when i try to connect to the easysoft odbc. the driver is installed (Name{Easysoft IB6 ODBC}; Version{1.00.01.70}; Company{Easysoft Limited}; File{IB6ODBC.DLL}; Date{6/5/2002}) the user is the same administrator for the successful and unsuccessful attempts
Update: July 21:
1. Tried the installation that wasn't it.
2. Tried Operation system(cmdline) for using 32 bit detexec.exe failed again. (double checked and the command I used did work in the cmdline)
Here are a couple of things you must check (going from front end to back end). See what you are missing.
Run64BitRuntime is set to false in the project setting.
The same configuration setting (having Run64BitRuntime set to false) should be used for deployment.
If you are using an external configuration file, and that has this property, see that it is set to false.
SQL Server > Database Engine > SQL Server Agent > Jobs > Your job's properties > Select the step where you run the SSIS and click Edit> In the 'Execution Options' tab check 'Use 32 bit runtime'
Hope this helps!
"You can use our Interbase ODBC driver from SQL Server Agent or any ODBC enabled application. You will however need to install a 64-bit Interbase client that is compatable with your Interbase server before you install the Easysoft ODBC driver. This can be obtained from Embarcadero"
the issue appears to be with the software. In order to use easysoft on a 64 bit system i need the 64 bit driver properly installed.
Thank you #billinkc for pointing out the installation issue.
Related
I'm currently trying something I've never done before - I'm trying to access MySQL data in an SQL Server environment. Where I am, we have two servers (the MySQL and MSSQL servers), and each stores different types of data. Recently I've found a need to write queries that include data for both servers. One of the ways I read to do this is adding a "Linked Server" in SQL Server. But try as I might I cannot seem to get a Linked Server added.
I am working on a Windows 7 system, our SQL Server instance is 2005, and the MySQL version is 5.5.31.
What I've done so far is this:
Downloaded and installed the MySQL ODBC drivers
Created a System DSN using that driver for the MySQL database, called "Production". (I also tested the connection from the Data Sources application and it connects just fine).
Checked for the Provider in SQL Server (MSDASQL) to configure options such as "allow nested queries" and "allow 'LIKE' operator"
right click on Linked Servers in Server Objects in SQL Server > "New Linked Server"
From here, I fill out the linked server info like this:
Checked "Other data source" (not SQL Server)
Chose Provider "Microsoft OLE DB Provider for ODBC Drivers"
Product Name: "Production"
Data Source: (the name of the System DSN) Production
Then in the security tab, I chose the "Connections will be made using this security context" and provided my username and login for the MySQL server.
Then this is where I run into an error every time. I always get the following error message:
The linked server has been created but failed a connection test. Do you want to keep the linked server?
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.Express.ConnectionInfo)
Cannot initialize the data source object of OLE DB provider "MSDASQL" for linked server "FLUX".
OLE DB provider "MSDASQL" for linked server "FLUX" returned message "[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified". (Microsoft SQL Server, Error: 7303)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=09.00.5000&EvtSrc=MSSQLServer&EvtID=7303&LinkId=20476
If you click that link for help, by the way, nothing shows up.
I saw other people suggested trying an older MySQL ODBC driver, adding a System Data Source for the 32bit driver as well as the 64bit driver, and restarting my machine (not the DB server) -- none of these fixed my error.
What I do not understand is why my System DSN seems to work and connect fine, but SQL Server cannot see the Data Source. Does anyone see what I'm missing, or what I might be configuring incorrectly?
EDIT
Clarified that I restarted my local machine, but not the DB server since trying to add the Linked Server.
From everything you've said, you probably have a mismatch between bitnesses of SQL Server 2005 components and the installed ODBC Driver for MySQL.
System DSNs are definitely the way to go.
You probably will need to install both the 32-bit and 64-bit ODBC driver, and configure an identical (same name and everything!) System DSN with each.
I would say you may also want/need to install this patch it was useful for getting XP and 2003 to work properly for ODBC type connections for me.
http://www.microsoft.com/downloads/details.aspx?FamilyID=000364db-5e8b-44a8-b9be-ca44d18b059b&displaylang=en
Is your Database server on the same machine on which you have Sql Server Management Studio Installed? If the SQL Server is on a remote machine then you need to install the ODBC driver on remote Machine and create the DSN there as per link
I was having the same issue but the above link solved my problem.
It has been a real struggle trying to get this to work on my Windows 7 64-bit machine.
I have a package which moves data from Oracle to SQL and, on our Windows 2008 R2 test server it works fine (within BIDS).
What I have tried so far....
Copied BIDS from Program Files (x86) to Program Files (to eliminate
the brackets issue)
Installed 32-bit and 64-bit Oracle as well as 32-bit ODAC.
Tried setting DelayedValidation to TRUE
Installed TOAD and am able to connect to Oracle database.
Within BIDS, I can test the connection successfully and even preview it, however when I try to execute the package fails on the DataSource task (ie Oracle connection).
Very frustrating and I appreciate any help on this.
Complete error below:
[OLE DB Source [1]] Error: SSIS Error Code
DTS_E_CANNOTACQUIRECONNECTIONFROMCONNECTIONMANAGER. The
AcquireConnection method call to the connection manager "LICS" failed
with error code 0xC0202009. There may be error messages posted before
this with more information on why the AcquireConnection method call
failed.
[SSIS.Pipeline] Error: component "OLE DB Source" (1) failed validation
and returned error code 0xC020801C.
thanks,
KS
Try doing this since your driver is 32 bits.
Right click on project > properties > Debugging > Run64bitsRuntime > False.
You guys are going to laugh.... but I set Run64bitsRuntime to TRUE and it works lol! I guess it is using the 64-bit driver then - now I'm confused. I dont even want to know whats going on here as long as it works!
The error message is:
POSTGRES dm_genders_d failed validation and returned error code
0x80004005.
I've seen several references to this almost assuredly being a permissions issue, which sounds right to me, but I have been completely unable to identify the relevant permissions.
The Postgres connection is using ODBC. The package is moving data from PostgreSQL to SQL Server. Currently both 32bit and 64bit drivers exist, but I haven't seen how to choose between them.
I have made all of the recommended changes to 32 bit for the job.
We are using Windows Authentication.
I've set up a proxy to execute the job as my user.
None of this has alleviated this error.
UPDATE: Yes, the 32 bit data source has been defined, and it is being used.
I had this error and I could solve it by Add ODBC connection in the "system DSN" instead of "User DSN" tab.
Start > ODBC Data Sources
Also I ran package with 32-bit runtime
for this: right click on your job in SQL Server Agent > properties > steps > edit
in the window that appear (Job Step Properties) you can set 32-bit runtime. (below picture)
I have an SSIS package that takes data from a MySQL database and puts it in to a SQL Server table. The connection to MySQL is ADO.net. The package runs fine in BIDS.
I would like to deploy the package to be run as a Job on SQL Server 2008. The MySQL connection requires sensitive data to be either stored within the package or held in some external configuration source. If it is stored within the package it will either by encrypted with a key specific to my windows user profile or must be protected via a password.
I have tried three methods of setting up a SQL Server Agent job to execute this pacakge, and all fail:
Using a Password
I set the ProtectionLevel of the package to EncryptSensitiveWithPassword and supply a password for the package. I then save a copy of the package to the msdb. I can then connect to SSIS and run the package, at which point I am prompted for a password.
When I try to schedule this as a job in SQL Server I am prompted to enter the password by clicking on the Configurations tab of the Job Step Properties and I can see that the /DECRYPT switch has been added to the Command Line tab. The Run As property is set to the SQL Server Agent Service Account, which is mapped to a database login that has sysadmin server role. When I attempt to start this job I get the following error:
Executed as user: DOMAIN\UserROLE. Microsoft (R) SQL Server Execute Package Utility Version 10.0.5500.0 for 64-bit Copyright (C) Microsoft Corp 1984-2005. All rights reserved. Started: 12:31:30 Error: 2012-07-03 12:31:31.20 Code: 0xC00291EC Source: Get Data Execute SQL Task Description: Failed to acquire connection "DATA_SOURCE". Connection may not be configured correctly or you may not have the right permissions on this connection. End Error DTExec: The package execution returned DTSER_FAILURE
It seems that using this method the package password itself is not stored anywhere for the job to access it.
Using an XML configuration file
I then created a copy of the package and set the ProtectionLevel to DontSaveSensitive and I set up a package configuration to store the MySQL credentials in an XML file. I then save this to the msdb and then when I run the package from
Integration Services I can provide a path to the config file, and all is well. However, once again when I set up a job for the package I point to a configuration file on the server but the job fails with the same error. I am wondering whether this is because the SQL Server Agent does not have an associated windows account that would allow it to read from the XML file stored in the file system.
Using a SQL Server table configuration
This time I created a copy of the package and set the ProtectionLevel to ServerStorage. I then created a [SSIS Configurations] table in the target SQL Server database. I modified the entries in this table to contain the password for the MySQL data source. Again, the package runs successfully from Integration Services, but fails with the same error as previously when run from a job. I have checked that the SQL Server Agent is able to read from the [SSIS Configurations] table ok - I set up a standalone job to test this.
Does anyone have any suggestions about what else I should do here?
I am thinking of giving up on SQL Server Agent Jobs for this and going back to having the package scheduled simply by the windows scheduler but thought before throwing in the towel I would try here first.
I am using the method of encrypting the password by setting EncryptSensitiveWithPassword as you discribed above and don't see anything you do wrong. Remember to use option keep protection level of the original package when importing the package with integration services, but it looks like you're doing that, too.
Try setting the role SQLAgentOperatorRole to your SQL Server Agent Service Account, you didn't mention that and i am not sure if you did. This could possibly solve your permission problems. (liked to answer by commenting this, but i lack of permissions here, too :)
I just installed SQL Server 2012 to test differences and make sure it is ok for my Work. I may not be a pro at SQL, but I don't see how to add a Link to Jet database on my server. I have imported Jet Databases, but when going thru the GUI to Link a JET Database I see no Provider for JET. I am running Access 2003 (I don't like the 2008+ GUI)
I searched an found nothing simular to my issue; at least nothing I understood. Nothing mentioned how to add Jet db Provider.
I ran a connection string to the Jet Database thru QA:
sp_addlinkedserver 'USGEScrub', 'Access', 'Microsoft.Jet.OLEDB.4.0',
'D:\Lead$\SupList\USGEScrub.mdb'
The connection string works till I try to access the data and then I get this the errorand of course if I click the links nothing shows up:
TITLE: Microsoft SQL Server Management Studio
Failed to retrieve data for this request. (Microsoft.SqlServer.Management.Sdk.Sfc)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&LinkId=20476
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch.
Cannot create an instance of OLE DB provider "Microsoft.Jet.OLEDB.4.0" for linked
server "USGEScrub". (Microsoft SQL Server, Error: 7302)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&ProdVer=11.00.2100&EvtSrc=MSSQLServer&EvtID=7302&LinkId=20476
download the 2010 Access database engine from Microsoft
Allow "InProcess"
Add linked server using the ACE OLEDB provider.
more details here
I had a similar problem and in my case it turned out to be related to the permissions on the %TEMP% folder for the account under which the SQL Server service was running. For more details see my answer here.
Sometimes this problems occurs in computers x64 with office x84 versions installed. Try this:
Install pasive OleDb Driver x64