I have a web app, written about 10 years ago (VB.NET/ASP).
It uses the following connection string to connect to dBase 5 files:
Driver={Microsoft dBASE Driver (*.dbf)};DriverID=277;Dbq=[SOURCE_PATH];
This has been working great for years.
Now we are moving this app to a 64 bit server, and this connection is now giving me
ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
I've read numerous suggestions in numerous threads, including changing the above connection string to
Microsoft.Jet.OLEDB.4.0; or Microsoft.Jet.OLEDB.12.
but that didn't do anything.
I also tried setting Enable 32-Bit Applications settings on the application pool on the web server to TRUE, but that resulted in
HTTP Error 503. The service is unavailable
Can somebody point me in the right direction please??
Try to change your connection string from
Driver={Microsoft dBASE Driver (*.dbf)};DriverID=277;Dbq=[SOURCE_PATH];
to
Driver={Provider=Microsoft.ACE.OLEDB.12.0;Data Source=[SOURCE_PATH];Extended Properties=dBASE 5.0;}
You also have to change your code from ODBC objects (DataSet, etc), to OLEDB objects.
Related
When we migrated from .NET framework to .NET core, we had to change the format of our iSeries connection string from using Server= to using Data source= and to include port#, but also we had to include Database= because without it the connection string could not be assigned to a connection due to an "Invalid argument" exception. With absolutely anything for a database, we always get a uniform error message:
ERROR [08004] [IBM] SQL30061N The database alias or database name \"QSYS \" was not found at the remote node.
(Notice extra spaces in the DB name)
No matter what we supply for a database, the error is always the same. We tried our actual library name similar to app0123 that is reported by DSPLIB or QSYS etc.
We also tried databases reported by DSPRDBDIRE named similarly to IHST0123 but in this case the error was different:
ERROR [42968] [IBM] SQL1598N An attempt to connect to the database server failed because of a licensing problem.
We know that there is no licensing problem with the server because it is our production environment that many applications in Java and C# connect to.
Our usual practice is that if an application App1 connects, it uses app1 user name and app01, app02 etc schemas, app01 being the default one. Therefore, we only ever had the iSeries host name like IHST01 etc in the connection string, and we added user ID and password through the connection string builder.
We are having no issues connecting through .NET core connector to DB2 LUW since database on it is very apparent and unambiguous. Since we never had to specify an iSeries database under .NET framework, it is not clear what it has to be. Does anybody know?
The library (aka schema) name is not the database name.
The *LOCAL entry in DSPRDBDIRE should be your DB name.
A better tool is IBM Access Client Soultions (ACS) "Database -->Schemas" tool which has a UI like so:
On the connected server (ut29p63.rch.stglabs.ibm.com), there are (at least) two databases:
ut29p63
Dbtest
I'm surprised you don't think the DB name was needed for .NET Framework or Java as I've always needed them. If you've only got one database on your IBM i, as is common for smaller boxes, it's possible the DB name matches the system name.
Judging from the license error message, you are getting connected.
However, the .NET Core nuget packages use the IBM Db2 Connect driver. This driver is included for Db2 for LUW, and with an appropriate and optional license allows connecting to IBM Db2 for i or IBM Db2 for z/OS.
In other words, the Db2 Connect driver can always connect to Db2 LUW but you'll have to pay for an enhanced license to connect to IBM i or IBM z/OS. See IBM Db2 Connect License Types You'll need an Enterprise license or an Unlimited Edition for System i.
If you were using Db2 Connect driver for your .NET Framework, the same license will work for .NET Core (assuming the Db2 Connect versions match).
However, if you were using the free ODBC/OLEDB/ADO driver for .NET Framework, then you'll need the Db2 Connect license for .NET Core.
I recently upgraded from Windows 7 to Windows 10 and had to reset some remote database connections. I had previously been connecting quite successfully to an Oracle database using the Oracle 11g client and RODBC.
library(RODBC)
channel<-
odbcConnect(dsn="myoracleDB",
uid='myusername',
pw='mypassword',
believeNRows=FALSE)
result<- sqlQuery(channel,"select * from schema_name.table_name")
close(channel)
Since the Windows 10 upgrade, the above connection protocol no longer works. Specifically, I get the following error:
channel<-
odbcConnect(dsn="myoracleDB",
uid='myusername',
pw='mypassword',
believeNRows=FALSE)
Warning messages:
1: In RODBC::odbcDriverConnect("DSN=myoracleDB;UID=myusername;
PWD=mypassword",:
[RODBC] ERROR: state HY000, code 12170, message [Oracle][ODBC]
[Ora]ORA-12170: TNS:Connect timeout occurred
2: In RODBC::odbcDriverConnect("DSN=myoracleDB;UID=myusername;
PWD=mypassword",:ODBC connection failed
Two additional observations are relevant here:
I use the Windows command line to execute tnsping myoracleDB which returns a successful connection to the database
I can also use Oracle's SQL Developer Application to successfully connect to and query from the database.
So I feel confident that the Oracle Client and the ODBC Data Sources are set up correctly.
Interestingly, I AM able to connect to my database using the RODBC library if I use the following code:
mycon = odbcDriverConnect("Driver={Oracle in OraClient11g_home1};
Dbq=myoracleDB; Uid=myusername; Pwd=mypassword;",
believeNRows=FALSE)
My question for the community is:
This new connection protocol works (which I'm happy about). However, since I don't really understand why it works when the approach that worked before no longer works, I fear I may be ignoring some underlying problem that could really hurt me down the road.
I have found the following SO threads to be helpful, though neither really addresses my issue exactly:
Failure to connect to odbc database in R
Connect to ORACLE via R, using the info in sql developer
UPDATE:
I have accessed the Windows ODBC 64 bit menu and verified that I do have a DSN called "myoracleDB" which is assigned to the "Oracle in OraClient11g_home1" driver. I have tested this connection and find that it works fine. I have also used the RODBC line:
odbcDataSources()
in RStudio and found that the data source "myoracleDB" is recognized. However, when I try to execute:
channel<-
odbcConnect(dsn="myoracleDB",
uid='myusername',
pw='mypassword',
believeNRows=FALSE)
I still get the error:
"TNS: Connect timeout occurred ODBC connection failed"
If you check out the docs, DSN=myoracleDB tells RODBC to connect to the Windows DSN "myoracleDB", while Dbq=myoracleDB tells RODBC to connect to the TNSNAMES entry "myoracleDB". They're two different ways of resolving database names. tnsping and SQL Developer also both use TNSNAMES to resolve databases.
So I think your DSN probably got deleted when you reset things. You can test it by going to Control Panel > Administrative Tools > Data Sources (ODBC). If your database is there, you should be able to Configure it and click Test Connection to make sure it's working. Otherwise you can add it there, and your original configuration should work again.
I am trying to set up an .accdb as a datasource on the reporting server. The database is local on the server and I have followed all the instructions to create a 32 bit and a 64 bit ODBC connection for .mdb and .accdb. I set up the data source on the Report Manager site as ODBC with dsn=dbname and test the connection and it is successful.
From the Report Manager site, I open a report in Report Builder. I add a dataset and point to the shared connection. Test connection is successful.
I create a new data set based on this data source and click Query Designer and get this error: Unable to Connect to Datasource dbname. ERROR [IM014] [Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application.
Then I prompted for credentials. Of course nothing works there. And this particular .accdb has only Admin with no password anyway. All users can access it.
The error makes me think there's a 32 bit vs 64 bit conflict. The .accdb is 32 bit, but Report Manager only sees it with the 64 bit connection, then tanks when I try to create the data set.
I've set the same odbc connections up on my local machine and on the server. Still no dice. Any and all help would be appreciated.
I kept working on this and was able to create a data source with the following connection string:
Driver={Microsoft Access Driver (*.mdb, *.accdb)};Dbq=\server\path\database.accdb;Uid=Admin;Pwd=;
I edited the report and used query builder to test the query and results. Query builder allows me to see results. Yay! Progress!
But now when I preview/run the report I get the following:
An error has occurred during report processing. (rsProcessingAborted)
Query execution failed for dataset 'dataset1'. (rsErrorExecutingCommand)
For more information about this error navigate to the report server on the local server machine, or enable remote errors.
Any ideas?
I was able to make this work. I had to install the 32 and 64 bit drivers on both the reporting server and the local (editing) machine. I created identical DSNs (32 bit and 64 bit) on each machine. Then set up the datasource with an OLE DB connection string.
Once complete, I was able to write reports against the database (but not browse tables). Other users could access the report from their own machines without the ODBC connections or drivers installed.
We'll call this a win. On to the next problem.
I have been using R for the last year for but it is the first time I need to import data through a SQL server. My data source is there, but for some reason R Studio fails to establish a connection and gives me following error:
[RODBC] ERROR: state IM002, code 0, message [unixODBC][Driver Manager]Data source name not found, and no default driver specified
I have searched a lot online but all advice given refers to creating a dsn, but in my case the data source name has already been created. I am accessing R Studio on a web browser through R Studio Server.
Thanks in advance
At the end it turns out that the issue was due to the company R Server being high trust, and the server I was trying to connect to is default trust. So the company's IS team is working on enabling SQL to pass through high/default trust servers.
I have an asp page which brings data from DB through ODBC connection, but it's failing. The stored proc is defined in the asp page which brings the data, SP seems to be fine but data is not coming.
Post the error, blur your passwords (hope that box isn't exposed.)
Your error is likely a missing ODBC driver. Check whether your sites AppPool is running 32 bit or 64 bit, then check the respective ODBC Manager to see if the driver you are using exists on the machine. If not go download one for whatever database server you are using and install it.
If you have windows 8+ or 2012 Server + on the server, just use the start screen search to find the ODBC managers, can't remember their run commands, and their difficult to find in the UI, I don't even remember where they are.
This commonly happens when people switch their app pool from 32 bit to 64 bit in a server upgrade, or just to run 64 bit. There are two versions of ODBC drivers, one 32 and one 64 bit. If you don't have the 64 bit ODBC driver and switch the app pool to 64 bit, your DB access will time out or fail. ASP commonly has "On Error Resume Next" all over the place, so might be eating the error and showing something generic instead.
I have sorted out this issue.Commented out the ODBC section and created a new SQL connection string directly in the asp page-
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open strConn
"Provider=SQLOLEDB;Server=SERVER\INSTANCE;Database=DBName;UID=*;PWD="