I am trying to download IBM iSeries ODBC Driver from IBM Wbsite, following error pops up
"An error has occurred
This product is subject to strict US export control laws. Prior to providing access, we must validate whether you are eligible to receive it under an available US export authorization.Your request is being reviewed.Upon completion of this review, you will be contacted if we are able to give access.We apologize for any inconvenience"
How do I get over this? Or is there any other way to create a connection to an IBM database via ODBC withour requiring this driver?
Pleas help
I have tried using SQL Drivers present in the ODBC Administrator bu they do not work.
This site provides info on a number of OSS packages for IBM i, including an ODBC driver.
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'm trying to connect to an Azure SQL Server (12.00.1900) from R on a Mac, using Microsoft's unixodbc SQL Server drivers (17).
I get a connection, but instead of seeing the 12 or so tables that live in the database, dbListTables returns 442 tables, all with nonsensical names, beginning with 'Csoe', 'Ote', and ending in 'xlshm_idad'. Instead of seeing the single schema that lives in the database, I see cin_1mro__e, IFRAINSHM, and s, none of which have any tables in them.
Note that when I use an ordinary SQL visualization app, that doesn't use the MS drivers, I'm able to see the tables and their content properly.
In addition, the RSQLServer package gets a working connection and sees the tables correctly, but isn't compatible with dplyr semantics.
Can anyone help or advise? I've looked for third party SQL Server unixodbc drivers for Mac, and I can't find any.
Until I see more info from OP, I'll leave as my answer the general recommendation to use R's odbc package. Assuming the correct drivers are installed, connection is configured correctly in odbc.ini, and assuming trusted_connection=yes is used in the same, then connecting from R is as simple as:
library(odbc)
dbConn <- dbConnect(odbc(), dsn = "myDSN")
if trusted connection is not on then you just need to pass uid and pwd arguments.
Also, it may be the case OP that you did not install freeTDS, so try (replace with equivalent for package manager you're using):
brew install freetds --with-unixodbc
This gives you the libtdsodbc.so driver. Make sure the DSN points to this.
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'm trying to connect OBIEE to Impala. Where I try my test, I encounter a problem that I can't
resolved,here comes my steps:
download the Cloudera latest Impala ODBC driver for windows,and import metadata from impala,I can finally successfully see data in Admin Tools like this:
upload the rpd file to the server,and download cloudera impala odbc driver for linux,and configure it,in the end ,I can do it like this which shows I have configure the driver successfully:
I try to create new analysis through 【Create Direct Database Request】 to test weather I can successfully connect Impala, but I can never connect it due to the reason like this,I can never fingure out why:
Is there anybody successfully do it or tell me how I can resolve the problem? Thanks!
I recommend connecting directly to Hive instead. According to Oracle's documentation Impala connectivity is not directly supported. OBIEE is built connect to Hive and Impala is not referenced:
http://docs.oracle.com/cd/E28280_01/bi.1111/e10540/deploy_rpd.htm#BABGIAJH