I have a package that imports from a AS400 file to SQL. The package executes properly within Visual Studio, but fails when set up as a scheduled job. the error message is that my password is incorrect. I know that it is correct. I also setup a package configuration and this did not work. I have searched and tried many things. Could someone give me some assistance?
Your password is incorrect.
Seriously, you "know" that your password is correct? You know better than the code attempting to use your password? Does this seem likely to you?
Consider the possibility that you and SSIS may be referring to different passwords. Maybe the one you "know" is correct actually is, but the other one is not.
Possibly a stupid answer, but how are you connecting to the AS400? If it's using ODBC drivers, you'll need the AS400 drivers installed on both local (dev) and your SQL server box. They're notoriously picky about versions.
If memory serves me correctly, when you set up the ODBC connection using the AS400 driver software, I think you need to specify connection details as well and they get explicitly saved in the ODBC connection.
The support link above is correct. To boil it down to a simple answer. Password protect your SSIS package to save the credentials needed to connect to the AS400.
With the ODBC configuration: use a system DSN instead of user DSN, it will work!
Try to use odbc connection or try to redeploy the package on your SSIS Server.
Related
We have a POS system running a Firebird database and the rest of the business is on SYSPRO which is SQL Server based.
I would like to run queries and views between the databases as both databases have unique keys which can be matched.
Do I do this through a Linked Server? I have tried a few variations of linked server and I keep getting various error messages. So this is what I have so far:
EXEC master.dbo.sp_addlinkedserver
#server = N'OMNI',
#srvproduct=N'OMNI',
#provider=N'MSDASQL',
#datasrc=N'C:\Omni\Company\Data\databasefile.FDB',
#provstr=N'Driver={Firebird/InterBase(r) driver};Dbname=C:\Omni\Company\Data\databasefile.FDB;CHARSET=NONE;UID=SYSDBA;'
I have also tried connecting using Excel and I can see the database and view the tables using the following connection string:
Provider=MSDASQL.1;Persist Security Info=True;Data Source=Omni;Extended Properties="DSN=Omni;Driver={Firebird/InterBase(r) driver};Dbname=C:\Omni\Company\Data\databasefile.FDB;CHARSET=NONE;UID=SYSDBA;";Initial Catalog=Omni
Ok here is the answer (I have a short patch of hair left after this ;-) )
I cannot answer the technical questions as to why this works, but it works.
Firstly you need to install
Firebird 2.5
Then the 32 Bit Driver
32 Bit
Then the 64 Bit Driver
64 Bit
Then you go to you Command Prompt (administrator). Goto where you installed Firebird 2.5. In my case it was
C:\Program Files (x86)\Firebird\Firebird_2_5\bin\
Then enter:
fbguard.exe - a
This will get a version of the Firebird server going.
Then it is a simple setup of an ODBC link.
If you are trying to link to a local instance of the database, do not forget to put
localhost:\Company\Data\Companydata.fdb
The short answer is yes, it works (having the correct driver, sql side).
Let me try to simplify this scenario. In fact, it is not clear what kind of installation is the OP speaking about.
SQL Server must use either ODBC or OLE DB drivers. unfortunately, official Firebird drivers are dated 2017. Some third parties do them, devart, ibprovider, ibphonix, etc. I did my tests using the ibprovider ones.
The initial post is showing this connection string (partial): "Dbname=C:\Omni\Company\Data\databasefile.FDB".
Said that the traditional style for connecting via TCP/IP is
"IP address/port:database_file_path", the OP's seems to face with an embedded Firebird installation.
The difference is that, in this latter case, there is no Firebird service answering requests. Everything is done via a DLL, that's usually named fbembed.dll.
Installing Firebird as a service, as proposed, certainly fix the issue, because, after this installation, there is a (Windows) service always running and taking care of databases. However, if you do not want/need this service, MS SQL Server can work with the "embedded" installation too.
The main rule, I hardly discovered, is: the bunch of needed Firebird DLLs (but fbembed.dll) must be installed in the Windows system folder (in the manual it is reported exactly the contrary...).
To sum up, I have built a working server in this way.
0) I have benn always useing the ibprovider driver because their developers provide a great support service. And, some basic instructions can be found here too: https://www.ibprovider.com/eng/documentation/mssql_2012.html
1) I started downloading the official embedded package.
2) In the data folder, I have put the database, the fbembed.dll, and the firebird.msg
3) In the windows system folder, I have registered the minimum firebird DLL needed: icuuc30, icuin30, icudt30, and ib_util.
4) I've then created a linked server (yep, OPENROWSET is exactly the same) using the following string (if you need the fbclient.dll, simply copy/paste the embeded.dll and rename it):
EXEC master.dbo.sp_addlinkedserver #server = N'myName', #srvproduct=N'myName', #provider=N'LCPI.IBProvider.3', #datasrc=N'myName', #provstr=N'location=E:\mypath\MYDB.GDB;dbclient_library_64=E:\mypath\fbembed.dll;auto_commit=true;nested_trans=true;truncate_char=false;dbtime_rules=1;support_odbc_query=true;asynch_fetch=2;ignore_err_param=4;schema_ldr_cfg__check_constraints=0;schema_ldr_cfg__descriptions=0;dbclient_type=fb'
5) Security isn't a concern. The DLL does not manage it, BUT you need to pass a userid/password pair:
EXEC master.dbo.sp_addlinkedsrvlogin #rmtsrvname=N'myName',#useself=N'False',#locallogin=NULL,#rmtuser=N'SYSDBA',#rmtpassword='anytring'
6) you do need a couple of special options to be set to True: Collation, Allow inprocess, RPC, RPC Out.
Yes it works. And it saves at least a couple of MB ram as you haven't an always-run service.
Last but not least, thanks to the ibprovider.com developers that help me to sort it out.
Yes, I lost the password to an SSIS package in 2008 R2. Is there any way to recover the package? Has anyone been able to open a password protected package without having the password?
Thank you
We had a recent problem where some developer who loved encrypting his SSIS packages with passwords forgot he even worked on it and it broke.
Luckily, (and as far as I know this is the only way) if your package is set up to run via a job on the SQL Agent you can recover the password like this:
SELECT sjs.command
FROM msdb.dbo.sysjobs sj
JOIN msdb.dbo.sysjobsteps sjs ON sj.job_id = sjs.job_id
WHERE sj.name = '<job name here>'
There will be a portion of the returned command that looks like
".../DECRYPT -password here-"
Good luck!
No. If the encryption were reverseable then it wouldn't be much use, would it?
Chalk this up as yet another reason why encrypted packages are probably not that useful
If the package is also stored SQL Server database ('MSDB' in the SSIS tree in Management Studio), you should be able to export it to the file system: right-click, Export, select 'File System'.
You'll lose any sensitive data (connection passwords) in the package, but I'm guessing that's not the biggest problem you have.
I have scenario where I have several variables eg. sourceFilePath, sourceFileName and etc. I am storing the variables as a configurations in SQL Server Table. To store this configuration, we have to provide a connection (I have opted for OLEDB Connection).
When I am executing this from BIDS, it is working very fine and there are no issues at all.
I can change the sourceFilePath and sourceFileName from the Configuration table and the package is taking the changed path as well.
But the problem arrived when I have deployed the Package on SQL Server. I am not able to get the configuration values from table and it keeps on saying "Login failed from user.... Unable to load the configuration ...... ".
What can I do to avoide this situation?
Yes, I tried giving the password explicitly when scheduling the job but I can do the same for production server as it stores the password as a plain text.
Any help is highly appreciated.
Many thanks.
Thanks to all. I just need to set ProtectionLevel property for my packages and the rest is done. Such a small thing and it was making me nuts...
I'm trying to create a Database Connection to ODBC data sources in SPD 2007 and am having absolutely no luck. I've had some success using an SqlDataSource control, however. I don't know if SPD's database connection support is just broken or what. Googling has turned up others having issues but no definitive answers.
So, my two data sources are MySQL 5.1 ODBC and ProvideX ODBC. I pretty much have the same trouble with either, so I'll just focus on MySQL.
I've got a system DSN on the machine running SPD that is successfully connecting to the MySQL database. (This DSN also exists on the server running Sharepoint, if that matters at this time).
In SPD, I go the Data Source Library, expand Database Connection, and choose Connect to a Database. I then click on Configure Database Connection. Since neither of the providers in this dialog are appropriate, I choose "Use a custom connection string". I then set the provider to "Microsoft .Net....ODBC" and at this point I've tried the following connection strings.
First the DSN attempts:
Dsn=TheOneICreated (this one works from the SqlDataSource control)
and
Data Source=TheOneICreated
Then the more direct approach:
Driver={MySQL ODBC 5.1 Driver};Server=myServerIP;Database=dbName;User=username;Password=password;Option=3
The error I get back is always the same -
"Server Error: An error occurred while
retrieving the list of Databases from
: The server for the data source
returned a non-specific error when
trying to execute your query. Check
the format and content of your query
and try again. If the problem
persists, contact the server
administrator."
Am I fighting a losing battle here?
It looks like SD could be enumerating databases and/or tables so it has a list of tables and fields to 'help' you along....
Just a clarifying question or two..
Could this happen because SD is expecting a different way of enumerating tables? (Does it actually work with MySQL or anything ?)
What does your ODBC trace look like? (If #1 is true, you'll be able to see it and possibly create supporting views...if you truly need it to work with this particular dbms...)
Is this connection accessed from the sharepoint server? If so, do you need to define your dsn & driver there?
I've been put in charge of migrating a customer's website of MS SQL/ASP to PHP/MYSQL. I have zero experience with MS SQL.
I'm trying to figure out the best way to get the current data migrated to MySQL so I can begin PHP development.
Some details:
I downloaded SQL Server Mangement Studio Express. I found the following string in a connection file:
MM_connCompanyName_STRING = "provider=SQLOLEDB;data source=IP_ADDRESS;database=DATABASENAME;uid=USERNAMEpwd=PASSWORD;"
Using the IP, username, and password from this string, I could successfully connect using Studio Express.
I downloaded the MySQL Migration Toolkit and entered the same info, but get the following error:
Connecting to source database and retrieve schemata names.
Initializing JDBC driver ...
Driver class MS SQL JDBC Driver
Opening connection ...
Connection jdbc:jtds:sqlserver://IP_ADDRESS:1433/DATABASENAME;user=USERNAME;password=PASSWORD;";charset=utf-8;domain=
The list of schema names could not be retrieved (error: 0).
ReverseEngineeringMssql.getSchemata :Login failed for user 'USERNAME'.
I don't have admin or physical access to the current SQL server. I've tried to run some exports through Studio Express, but it saves them to the file system, which I don't have access to.
I can reach the current/old webmaster, but because he no longer works for the company, his responses are slow and usually un-helpful. So no help there...
The former admin sent me an MDF file ... no idea what to do with that.
I found this note above the connection info on the current server (if it means anything):
'this connection is being used because
ODBC was causing weird errors,
switching to OLEDB fixed them
My questions:
Any idea why this would be failing with the same login credentials that works with Studio Express? I'm assuming it has something to do with the driver, but I don't know what next steps to take.
Is there a better/easier/more effective way to migrate this data? (I'm hoping I don't find myself running "SELECT *" statements in Studio Express and copy/pasting data into Excel...please god, no)
Thanks in advance for your help.
Eww, this is going to be scary (connection string indicates it was tool generated from Dreamweaver, never a good sign).
Any idea which version of SQL Server? You should be able to SELECT ##VERSION. 10.x is 2008, 9.x is 2005 and 8.x is 2000. If it is 7.x run.
The MDF file is the actual database. If I were you, I would buy a developer edition of SQL 2005 (or 8 if it is 2008 which is unlikely), it will be worth the $99 or so it costs.
This will give you the ability to locally install the DB by ATTACHing the MDF file. Once you have a locally running copy, you can use the SQL Server ETL tools with the MySql ODBC drivers to push the data to MySql in a repeatable manner.
I believe you can export data from MSSQL choosing different SQL dialects; I believe there's one that's reasonably MySQL compatible. It doesn't solve all your problems, of course, because while you may get the structure properly, stored procedures and triggers and the like will take a bit more work. But that should get you started.