I am creating a package for updating a table in SQL server. The details to be updated is fetching from the MySQL database. For this I am using ODBC connection manager to connect to MySQL. But this ODBC connection manager is not getting listed in the OLE DB connection manager. I can see ODBC Source and destination in Toolbox. Similarly is there any ODBC lookup for doing this?
Lookup components only support the use of OLEDB connection managers or Cache connection managers. For your purposes, you should use the latter:
Read the MySql table using ODBC
Use the cache transform to load a .caw file.
Configure the lookup to read from the cache file.
I though of answering my own question as I got an easy solution for the same. Hopefully it will become a help to other beginners in SSIS.
Creating a Datasource for MySQL is an easy task. The whole process can be done with the steps mentioned below.
Install the MySQL connector.
Create ODBC DSN.
Create datasource using the created DSN.
Lets discuss each step in detail now.
1)Install the MySQL connector.
MySql connector is readily available for download in the MySQL web site. Download the correct one for your machine and install. It will be better if you install bot the 32 bit and 64 bit versions. When I tried using the 64 bit alone, I was getting an error regarding a platform mismatch.
2)Create ODBC DSN.
Open ODBC data source administrator. If your machine is 32 bit then open 32 bit other wise 64 bit ODBC data source administrator. Mine is 64 bit machine. It can be opened by Control Panel->Administrative Tools->ODBC DataSources. Mine is 64 bit machine. So I am opening the ODBC Data Sources(64 bit)
Go to System DSN tab. Click Add button. Below window will appear.
If the connectors are installed properly as per step 1, then they should be listed here. Select the MySQL ODBC 5.3 Unicode Driver. Click Finish. The below window will appear. Enter the credentials and Press Test button. If everything is fine, it should show a success message. Then Click on Ok Button.
Then the created DSN should be listed in the System DSN tab.
Repeat the same for User DSN also. Because in the SSDT while configuring the datasource we wont be able to select the System DSN. Also when deploying we wont be able to work with the User DSN also. Creating both in same name will save the package editing time. This is what happened in my case. I spent a lot of time investigating the reason for the package failure. Finally I got this. Please correct me if I am wrong. 🙂
3)Create datasource using the created DSN.
Add a connection manager in the SSDT by right clicking the connection managers in solution explorer and selecting New Connection Manager. Select ODBC from the options available.
Click Add. In the window that appears click New. A new window will appear.
In the data source specification select the Use user or System Data Source Name. Select the created DSN from the drop down box and press Test Connection. It should show success message.
That’s it. We created the ODBC source.
Please refer my blog for the article
Related
I have imported data to SQL Server Express from MS Access and have tried to link to the data from an Access front end file.
I have tried several different login types, but each gives me the same error:
Error Locating Server/Instance Specified
Please help.
Assuming a local instance of SQL server?
The default is usually YOURCOMPUTERNAME\SQLEXPRESS.
But, you can use a "." (dot) in place of your computer name.
So, the server name should be .\SQLEXPRESS
A few things:
When you setup and attempt to connect? Always create a FILE dsn. The reasons for this are many, but one really nice reason is that then Access will by default create a DSN-LESS connection. This approach is preferred since then Access remembers the settings, and no external settings (such as registry or even a file (dsn) is used or required. And if you connect to a SQL server on your network? Well then you can distribute the access application to each workstation, and it will "just work" - all without you having to setup a DSN or do anything with the ODBC manager on each station. So, a great tip and habit. So, use a FILE dsn (and if you follow the default prompts when linking tables, a FILE dsn is the default anyway).
Next up:
Make sure the sql server browser service is running. In the past this was often not required, but now it is recommended. That service is this:
Once you sure that service is running?
Make sure that you enabled named Pipes - in fact I would also enable TCP/IP. That is found here:
Ok, now the next question:
Are you using SQL server logons, or Windows authentication?
For now since this is your local stand alone machine? lets go with windows.
As noted, if you have SSMS installed, then see if it can connect. This not only is a quick + easy fast test but it will also tend to give you the hints as to what the server name connect is. (this helps you when you attempt to connect with Access - you can see what worked with SSMS - and better is SSMS does usually figure out the correct computer name for you.
So, from Access, you now choose from ribbon "External" data, and then import and link group - choose ODBC.
the wizard to connect will start. choose "link to the data source".
At this point, the panels that start to launch are the same one you see if you try to use the ODBC manager from the control panel - but in most cases this road is better, since Access will correctly launch the x32 or x64 bit ODBC manager (it makes this correct decision for you).
So you be at a DSN name, but just hit new. Now you have to choose a ODBC (for sql server) driver.
For now, I would try "SQL server". You can choose SQL Server Native Client 11 (or later if you see). Either one is fine. Just keep in future mind that SQL Server driver choice exists on all computers - so for future distribution to other workstations, this is a good choice. The native 11 (or later) driver is NOT installed by default, and you have to install this on other workstations if you want to use that driver if you move or distribute your application to other workstations.
Next, and now you can enter a name for this connection (myTestcon or whatever). Hit finish.
You should now see/be at this screen:
The dropdown for the server name SHOULD appear and work (it make take 30 seconds). So, it should show you a server name, and a sql instance.
Next, and now you have to choose the type of logon
Because this is a local stand alone computer? Well, you can choose windows logons, or sql logons. Being a local computer - choose the default - windows auth.
Next.
NOW VERY VERY important - make sure you change/select the correct database here - SO MANY skip or miss this - and that's painful!!
This one:
So make sure you select/change the default from "master" to your database you created when you sent the data to sql server.
Next - (you can try the test data source). "ok".
Now you are back to the VERY same starting panel. Your "name" should be defaulted for the file connection. This:
So, now just click ok.
You can then select the tables you want to link to.
I am attempting to use a Packaged Solution for my Access 2010 application that has its backend linked to SQL Server. At the moment, I'm using the .accdb file as the frontend, and I would like to distribute my application to some other Windows computers, but the Packaged Solution does not work. I had the package include Access Runtime, so their version of the frontend is running on Runtime and not full Access. However, once the application makes a request to the backend, the application does nothing, as I am not even prompted for the SQL Password as per usual with the full version. I've read on about including a .dsn file in the package can secure the SQL connection (see here), but going through steps of other tutorials to create .dsn files hasn't led to any results. Would anyone know how to correctly generate the .dsn file or if I've done something else wrong at this point?
(And yes, I understanding using Access 2010 in the year 2019 is almost a joke at this point, but I'm doing this for testing purposes. I plan to completely remake the frontend in Angular in the future.)
One other unrelated note... would it be a better idea to have the frontend hosted as a .html file like through the "Publish to Access Services" process? I did read that Access Services was discontinued last year, so would that not be possible?
Edit: This is not a duplicate of "DSN Less Connection (MS Access to SQL2016)" because A) I want to utilize a DSN Connection, not DSN-less and B) I am not using connection strings in my code to hook up with SQL.
You should be able to just create FILE dsn, link your tables, and then distribute the compiled accDE to each desktop.
However, what SQL odbc source provider did you use? If you use the SQL server ODBC provider, then that is by default installed on each computer.
However, if you linked using Native 11 (or later), then that driver is NOT installed on each workstation by default. So, I HIGH recommend you create a FILE dsn (not a user or system DSN), and link the table using that. (Access will create DSN-less links for you)
And you should NOT be seeing a logon prompt with your application. This suggests you forgot or missed the save password option.
So, I would re-link your tables, creating a new FILE DSN. And if you using the linked table manager, then make sure you check the prompt for new location to force creating of a NEW DSN. If you just re-fresh, then you DO NOT get a chance to click on the save password option during the linking process.
So, what odbc driver are you using? The native 11 or later are better, but they are not installed by default on each workstation. However, CAUTION is required here, since the older sql driver does NOT support the newer datetime2 formats. If you used these newer sql column types, they will be returned as string data types in Access and create a mess of issues.
So, first, I would re-link using a FILE dsn.
Make sure you check the save password during the re-link.
You then compile your accDB into an accDE, and then distribute that. You don’t really need to use the package wizard, since once each workstation has the runtime installed, then a simple copy of the accDE to each person’s computer will thus work fine. There is NO special connection between your accDE and the package wizard. Once the runtime is installed, then any and all mdb, accDB, and your accDE can simply be clicked on to launch + run. So for testing, you can skip the package wizard, and just copy the accDE to the target machine, click on it, and see if it works.
Edit
The prompt and check box during this process is this:
So you have to check that box to save the password. Note that you ONLY get this dialog WHEN you create a new FILE dsn.
Hi there hopefully this makes sense.
I have split the database into backend and Frontend.
In the frontend i also have added some linked tables from a SQL Database which are on the network. The DNS files are in the same folder as the front. Now when ive copied across the frontend to the end users desktop when they try to open the table via a form they get the error: "ODBC Call failed" anyone know why that might be?
1 of the end users is using the free version of ms access(2016 runtime) and other has full MS Access but both get the same error.
As it wasnt happening during the development stage on my computer and my collegues. I am a bit lost on how to fix the issue other than convert the linked tables to local tables and do a weekly update of them from the SQL server via my computer where the links work.
Seeing as a normal backend table that is linked to the front works fine. Just would like it to directly call the information from the SQl Server.
Make sure on your development workstation you link the table using a FILE DSN. When you link, Access then converts the links to what we call DSN-less.
The above means then you don’t have to copy or setup or use ANY kind of DSN on each workstation. So do NOT use a “system” DSN – that uses settings in the registry that you have to setup on each workstation.
The next issue to be aware of is which SQL driver you use to link the tables. If you use the “standard” SQL Driver when linking, then you can be SURE those drivers are installed by default on each workstation.
If you use “Native 11” (or later), then you have to ensure that the Native 11 (or later) drivers are installed on each workstation for this to work. The native drivers are better choice, but they are not by default installed on each workstation.
So I suggest you delete the links, or use the linked table manager to re-link the tables – just make sure you use a FILE dsn – since once the tables are linked, then Access ignores and does not use the DSN anymore – you don’t need it, and you could even delete the DSN and you linked tables will still work.
I have a server that is capable of creating and running an Excel Import task using the Import Wizard. I am trying to automate that process by using a visual Studio 2010 Integration Services package, that I am developing on that server.
The problem happens when trying to design the package. I have added an excel connection and pointed it at the Excel file on a local disk (the same file I have already successfully imported using the import wizard). When I add an Excel Source to the DataFlow and specify the excel connection, when I go to the Name Of the Excel Sheet Drop down I just see "No tables or views can be loaded" and get the following error.
"Could not retrieve the table information for the connection manager.
Failed to connect to the source using the connection manager ..."
I can't find this error logged anywhere and i don't know why it is failing. The directory is shared to Authenticated users and the file is not in use.
Any ideas how to debug this error? I understand there can be issues running this in 64 bit mode, but does that apply to development?
I should add that it is an excel 2007 file .XLSX and the connection is set to Excel 2007.
2019-11-08 The answer by GavB841 below looks promising, if anyone tries it and it works please let me know. (I am no longer working in this area.)
It seems like the 32-bit version of Excel was not installed. Remember
that SSDT is a 32-bit IDE. Therefore, when data is access from SSDT
the 32-bit data providers are used. When running the package outside
of SSDT it runs in 64-bit mode (not always, but mostly) and uses the
64-bit data providers.
Always keep in mind that if you want to run your package in 64-bit
(which you should aim for) you will need both the 32-bit data
providers (for development in SSDT) as well as the 64-bit data
providers (for executing the package in production).
I downloaded the 32-bit access drivers from:
Microsoft Access Database Engine 2010 Redistributable.
After installation, I could see the worksheets
Source:
Extracting Data From Excel with SSIS
The workaround is, I save the excel file as excel 97-2003 then it works fine
I also ran into this problem today, but found a different solution from using Excel 97-2003. According to Maderia, the problem is SSDT (SQL Server Data Tools) is a 32bit application and can only use 32bit providers; but you likely have the 64bit ACE OLE DB provider installed. You could play around with trying to install the 32bit provider, but you can't have both the 64 & 32 version installed at the same time. The solution Maderia suggested (and I found worked for me) was to set the DelayValidation = TRUE on the tasks where I'm importing/exporting the Excel 2007 file.
The recommendations from this article Extracting Data From Excel with SSIS resolved the issue for me.
I downloaded MS Access Database Engine 2010 32 bit driver
from the link in that article.
Also set Project Configuration Properties for Debugging Run64BitRuntime = False
In SQL Server 2014 SSMS (Integration Service Catalog -> SSISDB -> Environments -> Projects for all Packages in Validate checked box 32 bit Runtime.
My SSIS packages are working now in both VS 2013 and SQL Server 2014 environments.
Simple workaround is to open the file and simply press save button in Excel (no need to change the format). once saved in excel it will start to work and you should be able to see its sheets in the DFT.
You need to use an older version of the data connectivity driver (2007 Office System Driver: Data Connectivity Components) and select Excel version 2007-2010 in the connection manager configuration window.
I assume the newest data connectivity driver for Office 2016 is corrupt
Here's the solution that works fine for me.
I just Saved the Excel file as an Excel 97-2003 Version.
As discussed in the below:
Solution:
Go to https://marketplace.visualstudio.com/items?itemName=ProBITools.MicrosoftAnalysisServicesModelingProjects and install the latest version, it has a fix in there to resolve this issue.
Reference: https://developercommunity.visualstudio.com/content/problem/745991/could-not-load-file-or-assembly-microsoftdatawareh.html
A fix for this issue has been internally implemented and is being prepared for release. We’ll update you once it becomes available for download. For now, please install latest SSAS from https://marketplace.visualstudio.com/items?itemName=ProBITools.MicrosoftAnalysisServicesModelingProjects to work around the issue. Sorry for any inconvenience.
I faced the same issue. I think #Rishit answer helped me.
This issue is related to 32 bit/ 64 bit version of driver. I was trying to read .xlsx files to SQL Server tables using SSIS
My machine was pre-installed with Office 2016 64 bit on Win 10 machine along
with MS Access
I was able to read excel 97-2003 (.xls) files using ssis, but unable
to connect .xlsx files
My requirement was to read .xlsx files
Installed AccessDatabaseEngine_X64 to read xlsx, that given me
the following error:
I uninstalled the AccessDatabaseEngine_X64 and installed
AccessDatabaseEngine 32 bit, that resolved the issue
My answer is very similar to the one from #biscoop, but I am going to elaborate a bit as it may apply to the question or to other people.
I had a .xls that was an extraction from one of our webapps. The Excel connection would not work (error message: "no tables or views could be loaded"). As a side note, when opening the file, there would be a warning stating that the file was from an online source and that the content needed activation.
I tried to save the same file as an .xlsx and it worked.
I tried to save the same file with another name as an .xls and it worked too.
So as a last test I only opened the source .xls file, clicking save and the connection worked.
Short answer: just try and see if opening the file and saving does the trick.
Solution
Actually, if you are using SSIS in VS2019 then a problem could occur so do the below things:
Go to the excel sheet and save it again in .xls format.
Once you will use it in .xls format, automatically type will be coming as Microsoft Excel 97-2003 worksheet.
Like in the attached picture.
You will be able to load your sheet data.
I found that my excel file that was created in Excel 365 was incompatible with any of the versions available. I re-saved the excel file in 97-2003 version and of course chose that version in the dropdown list and it read the file OK.
you can try this:
Uninstall office365
then install only Access Database Engine 2016 Redistributable 64 bit
Also set Project Configuration Properties for Debugging Run64BitRuntime = False
It should work.
After researching everywhere finally i have found out temporary solution. Because i have try all the solution installing access drivers but still i am facing same issues.
For excel source,
Before this step you need to change the setting. Save excel file as 2010 format.xlsx
Also set Project Configuration Properties for Debugging Run64BitRuntime = False
Drag and drop the excel source
Double click on the excel source and connect excel. Any way you will get an same error no table or view cannot load....
Click ok
Right click on excel source, click on show advanced edit.
In that click on component properties.
You can see openrowset. In that right side you need to enter you excel sheet name example: if in excel sheet1 then you need to enter sheet1$. I.e end with dollar symbol. And click ok.
Now you can do other works connecting to destination.
I am using visual studio 2017, sql server 2017, office 2016, and Microsoft access database 2010 engine 32bit. Os windows 10 64 bit.
This is temporary solution. Because many peoples are searching for this type of question. Finally I figured out and this solution is not available in any of the website.
I've faced a bit strange problem. There is a site client would like to duplicate on another domain name. Site is built on ASP(yes, old v1 ASP :( ) with SQLServer. Problem is that all the database operations, including connection information is compiled into a DLL library.
Is there a way to some how intercept, override or workaround this?
Platform:
Windows 2000 Server
SQLServer 7
ASP v1 (VisualBasic)
What a nightmare...
If you have control over the new database server, and the connection string references the database server by name, you could add a line in the hosts file which points the name of the old server to a new ip address. Then you still have to create a user with the same password on the new database server.
Yes! However, your new database name MUST be smaller or equal to the length of your old one. Simply open up the vb6 .dll in any Hex Editor and search and replace. Make SURE you do not change the length of the DLL or shift any bytes around.
Failing that, add a hosts entry to windows to redirect the connection.
Could it be that the application uses a DSN definition for the connection?
In Control Panel -> Administrative Tools open ODBC Data Source Administrator. Have a look at the System DSN tab. Does there seem to be anything listed there that is related to the application?
Before you hack your DNS or rename the server, be aware that the SQL Server client supports aliases specifically for this scenario: How to: Create a Server Alias for Use by a Client.
The SQL 2000 tool for configuring an alias is the Client Network Utility.
Do you have any configuration options at all from asp? Even dbname or the such? If so you might be able to use two separate servers for IIS and use a single db server. I'm afraid you might need to find the source or the guy who wrote it.
If you could figure out the connection string or DNS you might be able to do something.
You could write your own passthrough ODBC provider.