My application generates a report, which pulls data from a mySQL server. It works fine on my machine but other machines could not find the runtime. After installing it, I get an error that it cannot open the connection on that other machine.
Do I have to install the ODBC runtime and add the connection to ODBC on every single machine I want to install my application on? Or is there a better way?
If you are using OBDC connection then:
1. You need to set up the connection again in other machine by using administrative tools, in addition too.. install odbc driver also.
2. Connection name can be the same with your local machine so that you don't need to update the connection name on your crystal report.
3. if you are using a hard code connection to your crystal report upon logging in then you need to open your project of course to update the connection.
Good luck.
Related
I have a 32-bit application that uses a UDL file to connect to a mySQL database on a different host. This 32-bit EXE is running on a Windows Server 2012 R2 VM. There was a HDD failure and I'm reconfiguring the system to connect to the database, so I know this configuration should not be so troublesome.
A snapshot of what is true:
MySQL ODBC Connector (32-bit) 8.0.23 is installed.
I created the connection with a unique DSN in the 32-bit ODBC admin panel.
Testing the connection through the 32-bit admin panel works fine (I can see the schema, etc.).
Here's where things start getting fishy:
When I open the UDL file my application uses to start the connection, the 32-bit DSNs don't show up. If I type them in manually, I get the 'architecture mismatch' error that everyone seems to agree actually means 'bitness mismatch' (If I create a 64-bit DSN, they show up and ping the DB no problem.)
I found this trick to open the UDL file using the 32-bit ODBC driver:
OLEDB is very similar in that there is a 32 bit version and a 64 bit version of the providers. The easiest way to configure and OLEDB data source is to create an .UDL file on the operating system. By double clicking on the .UDL file you will see the OLEDB providers for the 64 bit side of the operating system presented in the Data Link Properties dialog. To get to the 32 bit version of the OLEDB providers you need to execute the following command line from a command shell.
C:\Windows\syswow64\rundll32.exe "C:\Program Files (x86)\Common Files\System\Ole DB\oledb32.dll",OpenDSLFile C:\test.udl
...And that works! I can see the 32-bit named connections. The 'Test Connection' button produces happy output. But when I run my application, it does not connect using the DSN/credentials of the UDL file. It behaves like it is still trying to call the 64-bit version of the ODBC driver.
If my assumptions are correct, then how do I get my EXE to prioritize using the correct (x86) 32-bit oledb32.dll? Compatibility mode didn't fix my issue and I've run out of "clever" ideas to try.
Thanks in advance for any suggestions!
TLDR; I am attempting to connect to a host and hitting "To run a SSIS package outside of SQL Server Data Tools you must install Derived Column of Integration Services or higher". Does SSIS need to be installed on all Hosts for my package to succeed? Secondary question: If so, why would a manual execution from my dev machine work while the deployed/dtexec versions fail?
Apologies if this is a basic question (I am still steeping myself in all things SSIS and trying to learn as quickly as possible). Thanks in advance for any assistance you can provide!
I have a package that runs fine on my development machine (via Visual Studio). However, when I deploy the package out I encounter errors when attempting to connect to a MySQL database on a secondary host machine on the network. Taking a step back, I decided to attempt a manual execution via DTEXEC on my dev machine to attempt troubleshooting...
When executing this package through DTEXEC however, I encounter an error stating:
"To run a SSIS package outside of SQL Server Data Tools you must install Derived Column of Integration Services or higher"
Looking at the log, it looks like the package is able to connect to Host 1 successfully and do some data manipulation (one of the 3 hosts; I know Host 1 and Host 3 have SSIS installed). However, when it attempts connection to Host 2, it fails with the aforementioned error. For the longest time, I thought this was due to the MySQL database I am trying to connect to (using .net Provider\MySQL Data Provider) but given the error above, it is possibly pointing to something else...
After doing a bit of searching I have located the following articles which may be related:
https://dba.stackexchange.com/questions/49786/error-to-run-a-ssis-package-outside-of-sql-server-data-tools-you-must-install
Getting error running SSIS package on non-SSIS Server
I know SSIS isn't installed on Host 2. The package is being executed from Host 1 and this host does have SQL Server and SSIS installed. Host 3 additionally has SQL Server and SSIS installed and I am able to successfully operate/connect on this host as well. The only host presenting a problem is Host 2 which does not have SQL Server nor SSIS installed.
Do all hosts have to have SSIS installed for connections to be made? Additionally, if SSIS does need to installed on Host 2, why would my dev machine succeed while the dtexec/deployed versions fail?
Again, thank you for any assistance you can provide!
The answer to your first question is "Yes", and that fact is the answer to your secondary question.
In short, SSIS packages are NOT self-contained executable files. They are more like .ini files that the SSIS Service reads, interprets, and executes. If the SSIS Service is not running on a host computer, then that computer cannot do anything with an SSIS package (the .dtsx file).
Your dev machine succeeds because it has Visual Studio, or BIDS, which is a developer's version of the SSIS Service engine.
We've got a a series of SQL Server Integration Services packages that copy data from a few MS Access databases into a SQL Server 2008 database. There is one parent package that calls the various sub-packages, and that parent package is initiated by a user that runs a .bat file that executes the package like so:
dtexec /f "\\networkshare\package.dtsx" /CHECKPOINTING OFF /REPORTING EWCDI
This has worked fine for several years. Our IT department has begun upgrading our 32-bit Windows XP workstations to 64-bit Windows 7 and since they've upgraded the workstations of these users, the package has been failing, giving the error
-1071607037,0x,SSIS Error Code DTS_E_OLEDB_NOPROVIDER_64BIT_ERROR. The requested OLE DB provider MICROSOFT.JET.OLEDB.4.0 is not registered -- perhaps no 64-bit provider is available. Error code: 0x00000000.
An OLE DB record is available. Source: "Microsoft OLE DB Service Components" Hresult: 0x80040154 Description: "Class not registered".
My workstation has not yet been upgraded from Windows XP and I'm still able to run the packages but my ability to postpone the upgrade is running out and I need to figure out a solution as soon as possible. I've found many articles and posts related to this in my efforts to resolve the issue. Among the things I've tried are:
After ensuring that the users had the Client Tools and Business Intelligence Development Studio installed and that the path is valid, changing the contents of the .bat file to specifically reference “C:\Program Files (x86)\Microsoft SQL Server\100\DTS\Binn\dtexec.exe” in the hope that the 32-bit JET provider would be used
Researched the Run64BitRuntime setting but this appears to only have an effect while debugging and won't help me
Researched adding the /X86 flag to the command line but according to the MSDN article on dtexec, this only has an effect if the SQL Server Agent is running the task
The last thing I've tried was to install the Microsoft Access Database Engine 2010 Redistributable and change the connection string from "Provider=Microsoft.Jet.OLEDB.4.0;" to "Provider=Microsoft.ACE.OLEDB.12.0;". I can't seem to get off the ground with this one. If I try to create a new connection in BIDS and set the provider to "Microsoft Office 12.0 Access Database Engine OLE DB Provider" and test the connection, I get the error "Test connection failed because of an error in initializing provider. Unspecified error".
I'm just about at a loss for what else I can try and looking for any help at all, even if it's trying the things I've already tried, maybe I've configured something wrong while trying them originally, not sure.
Any help would be immensely appreciated!
In SQL Agent job or by just executing the package by itself there is a tab called "Execution options", you can select "Use 32 bit runtime" option
By default, SQL Server puts the 64-bit version of DTEXEC in the path. The 32-bit version should be located somewhere like C:\Program Files(x86)\Microsoft SQL Server\100\DTS\Binn and would need to be called directly. I had the same issue with the ACE drivers and Excel files.
See this for more information.
I was able to run it successfully by changing debugging setting in project property page. Property to change is Run64BitRuntime -> set this to false.
Having trouble getting my local IIS7 running C # MVC app to connect to a newly installed Sql 2008. IT was working wiht SQL Express, but we upgraded every machine to full SQL. Now, just my machine, will not connect to SQL 2008.
Followed many websites info, fooled wiht the user account both in IIS7 and SQL2008. Setting permissions to the DB's with db_owner(actually selected every permission) just not connecting.
I noticed the w3wp.exe service is not running. Not sure if that is the issue or if it was even running before.
Messed with the and tried all the sugeestions and tutorials out there that had to do with
Application pools are running, their set to the proper settings
IIs Account NetorkServices
Sql NT AUTHORITY\NETWORK SERVICE
created users for IIS APPPOOL\ASP.NET v4.0
When i check the sql logs there is no sign of it even trying to connect. The only message i get is when i restart IIs. Just says starting and stopping.
Been thru this before when i first tried to connect to SQL express, and was not this hard, and i did not touch anything in IIs when i installed sql 2008. So it should have connected.
Any other suggestions out there?
LLBL DataAccessAdapter should have string property ConnectionStringKeyName which contains app settings key (in web.config), which contains connection string. Visual studio does not use that connection string and you being able to connect to db from VS does not mean that connection string your application uses is valid.
Indirectly you lead me to the solution. lol
Started searching on running IIs and Sql 2008 on the same machine.
Running on a Win7 64bit, IIS7 an sql2008 R2.
Long story short, after hours and hours of fighting with IIS and SQL.
IIS7 --> Application Pools --> Select your pool --> Advanced settings --> General tab --> Enable 32-bit Applications set to true.
How it got to false, or why sqlexpress worked and sql2008 did not, not sure. But this fixed the issue.
I installed xampp on my computer and I want another computer to access the mysql db in vba. But, they don't have admin right on their computer and cant get it, and they dont have mysql ado driver installed.
Is there a way to do it without this driver - can I use a portable driver or a windows standard lib?
At the moment all I can do is create a php page and use post data with a sql query, getting the result as xml or whatever, which is really not what I want.
Without the correct ODBC driver the app won't be connecting to the database directly. You'll have to do through some sort of middle tier that does have the driver installed.
Your solution here is to have the user call the help desk and have them install the MySQL drivers on his PC. If this is business critical it shouldn't be hard to get it approved. If not you'll need to redesign the app to fit within the IT policies.