Is there way to enable bulk mode for odbc driver. I want to use IMDG driver that supports bulk mode but the Informatica shows this error "The session failed to run because bulk mode is enabled in the DSN entry. Disable bulk mode for ODBC."
hope this helps, you must have admin access to enable/disable it though I believe.
https://kb.informatica.com/howto/6/Pages/18/486011.aspx
Related
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.
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 developping a java application and i'm using JDBC to connect to MySQL Database, now i want to use ODBC to be able to get and retrieve data from any DBMS, of course if have access to it. Is there an API or tool to do this ?
What you are looking for is a JDBC-ODBC bridge. There are several available. It is not recommended, instead you should always use a native JDBC driver.
I'm working on some issues with psqlODBC's XA/MSDTC transaction handling and I find myself needing to obtain the server connection details (hostname, port, etc) from any user-supplied dsn programmatically without having psqlODBC invoked via the Driver Manager to do so.
Just parsed key/value string pairs will do; the problem is resolving user/system/file DSNs to get the underlying connection info.
The underlying issue I'm trying to solve is that a 32-bit application using MSDTC on a 64-bit system will supply a DSN that works for the 32-bit PostgreSQL driver. The 64-bit PostgreSQL drivers have different names - PostgresSQL ANSI vs PostgreSQL ANSI(x64) and similar for the Unicode drivers. So a DSN that works for a 32-bit app won't work for 64-bit apps ... like msdtc.exe. So I need a way to get the connection parameters the 32-bit app used and feed them into the 64-bit ODBC driver (or direct to libpq).
In the case of a DSN-less connection string like:
DRIVER={{PostgreSQL ANSI}};SERVER=127.0.0.1;PORT=5432;DATABASE=SOMEDB;UID=Administrator;PWD=;CA=disable"
I could just parse it to get the relevant info, but that won't work for file, system, or user DSNs where the XA transaction co-ordinator used by MSDTC only gets whatever the original user app passed to the ODBC layer - like:
DSN=SomeUserOrSystemDSNName
or
FILEDSN=C:\SomeFileDSN.dsn
and wrapped in that DSN is a DRIVER={{{PostgreSQL ANSI}}.
I've taken a look at the ODBC API docs and I don't see anything that seems to expose a way to load any DSN string, resolve file/system/user DSNs and get a parameter hash/map. OTOH, there's a lot of documentation out there, and some of the sections and function names aren't what I'd call predictable.
So - please tell me I'm missing something obvious, and there's a way to just:
GetDSNProperty("FILEDSN=C:\SomeFileDSN.dsn", "SERVER");
.. rather than writing hacky code to manually look up each DSN type.
I am trying to record datasource for sybase server, I am using ODBC protocol but the problem is once VuGen launch the application for recording nothing is coming up I mean VuGen is not able to record. I am selecting Rapid SQL.exe file. For ODBC do I need to select any other file??
Architecturally, how do you know that the application is using ODBC for connectivity and it's using the "right version" of ODBC? You may need another method.