SSIS ODBC pulls data properly until the package is executed - then it fails - ssis

I have an old database system of which I need to use Visual Studio to pull data into SQL.
This is what I have:
Windows Server 2012 R2
SQL 2012
Visual Studio 2010
On this server I have an ODBC data source with a special driver that points to the old database. It works, I have used it for years with other applications.
In Visual Studio, this is what I did.
Created an SSIS project
Created a new Connection in Connection Manager (lets called it “A”) using the ODBC Data Source.
Created a second Connection (let’s call it “B”) to the SQL 2012
In the Data Flow tab, I dropped in an ODBC Source, which I configured to use the “A”. The table shows up, proving that the ODBC Source is working. I chose a table then Preview – the top 200 rows appeared. So far so good.
In the data flow tab, I dropped in an OLE DB Destination, Which I configured to use “B”. I choose a table, then mapped the 2 together.
Now the problem. When I executed it, it failed with this: “SSIS.Pipeline: ODBC Source failed validation and returned error code 0x80004005.”
Why would the validation fail for ODBC when it properly pulled data?
How do I fix this?
I saw one article that I needed to add the path to the ODBC driver into the Windows path statement. I did that, but it did not help.
On a side note, I have Victual Studio 2019 on my personal computer. When I follow the exact same steps, it executes perfectly. The problem there is, SQL 2012 is too old to be published to, from VS 2019.

Related

SSIS Ingres 32-bit ODBC source, SQL Server 2014 64-bit destination issue

I know similar questions have been asked before...
I am working on a remediation project which requires to migrate an existing SSIS package from SQL Server 2008 32-bits to 2014 64 bits. The data source is an Ingres database (32-bit server, 2 tables). Some CRUD statements are performed in SSIS because updates a couple of tables on the SQL Server side.
It works beautifully on the previous platforms but with the SQL Server upgrade to 2014-64 bit it does not work anymore, with the famous error
The specified DSN contains an architecture mismatch between the Driver and Application
I have tried to set the "Run64bitRunTime" flag in the SSIS package to false, but then the OLEDB driver on SQL Server 2014 complains
An OLE DB error has occurred.... An OLE DB record is available.The AcquireConnection method call to the connection manager “” failed...
Out of curiosity when I tried to use the SQL Server Import and Export 32-bits program I can communicate with both Ingres and SQL Server 2014 and transfer data across from Ingres to SQL with no problem. I can save the Import-and-Export into a package but I really don't want to add all the SQL transformation statements from the original package to the new one (consider it is a remediation project).
I am now confused why the new package fails, but the Import and Export wizard works? Is there something I need to change in the new package to make it works in the new environment (apart from altering the Run64bitRunTime flag)
More information: I have tried to install the SSIS package as a file, or as part of the Integration Services Catalog, but both fail.
Any more information required please let me know. Thanks in advance.
I have resolved my problem by editing the SSIS package to make the SQL server data source to become OLEDB. It was painful to remap all the data columns though.

SSRS Issues with 32bit and 64bit ODBC drivers

The ultimate goal is for users to be able to run a report that looks pretty and grabs current information from our database. We'd like to use SQL Report Builder since we're already using it for other reports. The database is Cisco UCCX and we're accessing it with an ODBC connection from our reporting services SQL Server 2008 R2.
We've successfully setup System ODBC connections with both 64bit and 32bit drivers. When trying to access the connections though, we're receiving errors.
Using the 32bit driver, we try to create a Data Source in SSRS for use by Report Builder and receive the error:
"ERROR [IM014] [Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application"
Using the 64bit driver, we can successfully create and test the ODBC connection as a Data Source, but then when we attempt to create a Dataset with it in Report Builder, we get this error:
ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
Error received using the 64bit driver for ODBC connection
I ran into this recently. You need to have the same name for both 32 and 64bit DSNs. It's annoying because SSRS can run 64bit, but reportbuilder only exists in 32bit. So parts of reportbuilder seem to work (like running queries), but some don't (like refreshing query fields). Just have a DSN for both 32bit and 64bit, then make sure they're both the same name and the problems should stop.
You may be hitting an old but recurring issue with minor corruption in the Windows Registry.
The corruption takes the form of entries containing this 4-character string —
#=""
These entries aren't visible anywhere except Registry export files — the Registry Editor ignores them completely — but they can lead to a number of undesired behaviors, including the error you report.
NOTE: On your 64-bit Windows machine, there are naturally some complications tied to the 32-bit Registry. This Microsoft KB article may be sufficient to get you through these.
I suggest that you use the 64-bit Registry Editor (%systemroot%\system32\regedit) to export the following branches (where these problematic entries tend to be found) —
HKEY_LOCAL_MACHINE\Software\ODBC
HKEY_CURRENT_USER\Software\ODBC
HKEY_LOCAL_MACHINE\Software\WOW6432Node\ODBC
HKEY_CURRENT_USER\Software\WOW6432Node\ODBC
Edit these files in any text editor (Notepad or Wordpad are generally fine), and delete all lines which consist of that 4-character string, above. Then, delete the Registry tree segment(s) you exported, and import from the edited files — thereby restoring the tree segment(s), minus the corruption.
It won't hurt to repeat the above process with the 32-bit Registry Editor (%systemroot%\syswow64\regedit), but as you've described the issue, I don't think you'll find any #="" in the 32-bit export.

copy table content to same table on other sql server

I have used the wizard from http://sqlazuremw.codeplex.com/ to move my database from:
Microsoft SQL Server 2008 (SP3) - 10.0.5500.0 (X64)
Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (VM)
to
Microsoft SQL Azure (RTM) - 11.0.9164.122
Which worked great, but there was a table with over a gigabyte of rubbish data. So I stopped the process. Now it copied a table structure, but forgot to fill the content. I will have to fix this manually with query:
-- when connected to the azure db
select into azureDb.dbo.tablename select * onPremisesServer.onPremisesDb.dbo.tablename
But when I execute it, I get:
Msg 40515, Level 15, State 1, Line 16
Reference to database and/or server name in 'onPremisesServer.onPremisesDb.dbo.tablename' is not supported in this version of SQL Server.
I have found Cannot get Linked Servers to work in Sql Azure and it says that it is client related. So I looked up my version of SSMS:
Microsoft SQL Server Management Studio 11.0.3128.0
So that cannot cause this. I have also had troubles with the 'onPremisesServer' being just an ip address and had to execute select name from sys.servers to find a server alias instead of using [ipadres] for onPremisesServer. Still cannot get it to work. The tables have exactly the same schema.
edit as DeicLone123 mentioned, I used import and export data. I have renamed the table to tablename-old on azure and ran the wizard and got:
I used the 3.x again from http://sqlazuremw.codeplex.com/ to migrate just that last table. Easy as that! Manually transferring the data, column types etc. is a real pain.. So this open source migration tool is really recommended!

Visio 2010 DataSources not showing in reverse engineer wizard

Hi I am trying to do a database diagram in visio 2010 to existing database. I am using the reverse engineer wizard. When I push new button on datasource field. I follow the steps to add new datasource. It looks like everything worked no errors, tested connection and it passes. But after finishing the process it should add it to the datasource box so I can select and proceed on. But it does not show up. DataSource is still blank.
Specifics: It is a 2008 R2 Express db trying to connect to using visio 2010. OS is Window 7 64bit.
Can anyone help.
I had a similiar problem when creating the datasource as "file data source". Once I created it as user or system datasource it showed up. (Using Visio 2010 on WinXp connecting to SQL-server 2008)
It's really odd but it seems that using Generic OLE DB driver works for this issue.
I had the same issue, here is how I resolved it:
Beside Installed Visio drivers selected, MS SQL Server, at the bottom of the list, checked SQL Server Native 10.0
Under Data Sources, clicked on new, (I used User Data Source), then on the Create New Data Source Screen, used SQL Server Native 10.0
Upon completing the wizard, my data source did appear.
The main thing is to have SQL Server 10.0 checked beside on the Microsoft SQL Server option (not checked by default)

Migrating from MS SQL to MySQL: SQLOLEDB? Migration kit login error?

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.