Im trying to connect to an interBase database, using a program called Data Direct ODBC Driver for Interbase.
When i open Query1 which has fields from Table1 and Table1 is already opened, after some seconds i receive this message:
reserved error (-7713) there is no message for this error
and all the cells of (table1) shown "#deleted"
Can any one suggest how I may be able to solve this?
Updated 1-27-2015
Embarcadero who owns Interbase has an ODBC driver that is solid - http://cc.embarcadero.com/item/28975
I agree with #SamuelKDavis - the DataDirect driver will sometimes return NULL for columns which definitely have values. You can test this by creating a query and running it repeatedly through an ODBC connection and it will intermittently return NULLs.
We had also tried the IBProvider driver but ran into character set errors which we could not figure out.
Interestingly, if you lookup the history of Interbase, you'll see Borland actually made Interbase open source back in July 2000 at which point it was forked off into an open source database called "FireBird" - http://en.wikipedia.org/wiki/Firebird_(database_server)#History
Now the cool thing here is that the drivers that work with the old Firebird (v2.1 and prior) will also work with Interbase 6.0 all the way up to Interbase XE 64-bit, probably because the open source fork had not yet deviated from its Interbase roots. So try using Firebird v1.7 ADO.Net driver - http://www.firebirdsql.org/en/net-provider/
The newer Firebird drivers for .NET 2.0+ however do NOT work with Interbase.
Our company previously tried Data Direct with Interbase. It's terrible.
We suffered from random crashes using their driver, occasionally it would return nulls in the first column selected from the driver etc.
We moved to IBProvider (paid unfortunately), but have never come across an error since.
Related
We are using a Self-Hosted Integration Runtime for Azure Data Factory.
On that machine there was installed an Exasol ODBC driver of version 6. We wanted to upgrade the driver, deleted an old one and installed a new driver of version 7.
Weird thing is that now in Exasol logs we can see that Data Factory is sometimes connecting via driver version 7, and sometimes via driver version 6.
I made an experiment and deleted Exasol ODBC driver from the machine completely. After that Data Factory still was able to connect to Exasol using the driver I just deleted.
Looks like drivers' DLLs are cached somewhere. What can it be?
Update 1
I captured following actions in Process Monitor when Data Fatory connected to Exasol with ODBC driver of version 6:
Where these C:\Config.Msi\3739be5*.rbfASolution-6.1\ODBC\ DLLs may come from? There is no C:\Config.Msi\ directory on the machine.
Update 2
I noticed that when I test connection via Microsoft Integration Runtime Configuration Manager on the machine or in Data Factory Linked Service, then connection is always performed with ODBC driver of version 7.
But when I test connection via Data Factory Dataset, then in some cases connection is done with ODBC driver of version 6.
You could check the registry but clean at your own risk. An alternative might be the SysIternals tools, Process Monitor or Process Explorer which might help you get to the bottom of this. Install them on the SHIR VM if you are allowed to. Process Explorer in particular is a bit like SQL Profiler (if you've ever used that) so will be able to tell you which registry keys external processes are using. It will give you a lot a lot of information so you will have to make judicious use of timestamp and filtering. The proposed steps:
Start a trace using Process Monitor
Start a pipeline using the Exasol driver
Wait til it completes (or at least you know it has started)
Stop the Process Monitor trace Spend time going through the millions
of records it has captured, trying to filter down, or search for your
process
An alternative would be to build a clean SHIR and install only the new driver. Then swap it in for the old one. You may have to get the new SHIR added to the firewall if this is an issue for you.
Honestly I would propose both of these approached in parallel for a production problem. Procmon / Process Explorer can be quite labour and time expensive but should help you get to the bottom of the issue. Building a cleaner SHIR is probably a safer option in the long-term, but requires new infrastructure.
It may sound silly, but rebooting the server where SHIR is working solved the problem.
We noticed, that this server was running for more than 30 days, and decided to reboot it. Maybe restarting Integration Runtime service itself would also help, but we didn't do it.
Thanks to everyone for you help.
I've been trying to connect RStudio to a DB2 database and have been receiving the following error
rror: nanodbc/nanodbc.cpp:950: IM003: Specified driver could not be loaded due to system error 1114:
A dynamic link library (DLL) initialization routine failed.
(IBM DB2 ODBC DRIVER - DB2COPY1, C:\PROGRA~1\IBM\SQLLIB\BIN\DB2CLIO.DLL).
I've been using this code
connection<-DBI::dbConnect(odbc::odbc(),Driver="IBM DB2 ODBC DRIVER - DB2COPY1",
Server = "NRDCWIP6",uid="nxxx",pwd="Wxxx")
which has been working well for a different database (SQL server). I'm working in Windows 10 and don't have a lot of information about the database itself since it's managed by an IT group that's quite busy. I'm still quite new to connecting R to databases as well. I do know that the platform for the DSN is 32-bit, but when I look under the User DSN tab, it is listed as 32/64 bit.
I know 1114 is a rather well known error, but I'm not sure where the problem is and I've tried numerous variations of this code. Anything will help!
Here may be the answer for this situation:
Specified driver could not be loaded due to system error 1114
https://www.ibm.com/support/pages/specified-driver-could-not-be-loaded-due-system-error-1114
Here is the key note from above:
Resolving The Problem
Launch the odbcad32.exe from the Windows/SysWOW64/ folder and ensure that you have the current driver for the database version you are connecting to, specified in the Data Source that is being used in the map
Hope this helps.
We have code to connect to various databases and we get the driver version after connecting using the SQLGetInfo() call with the parameter SQL_DRIVER_VER.
However, we want the driver version in other cases too, e.g., before connecting, and in case of an error on trying to connect. The only way to get the driver version in these cases at least on Windows seems to be via the file metadata information of the driver DLL. The drivers on other platforms do not even have this file metadata.
So, is there a way to get the driver version using ODBC when we are not connected?
Thanks,
Ed
The ODBC API doesn't support this interrogation until the connection is live.
There are tricks you can bring to bear, such as those used by the iODBCÂ Administrator.app on OSÂ X. You might look into that source code.
I recently dug up a very old SQL Anywhere database. I have it installed and it kind of works, its only the distributed side of the data, so everything's running via dbeng50 and ODBC.
I would like to migrate this data to MySQL. Is there a way to do this? I attempted to view the data using an ODBC tool but I kept getting error messages saying the ODBC driver doesn't support the version of ODBC behavior.
I guess the database is too old (it's from 1997) - that put's at it SQL Anywhere version 5.
Its also difficult to find the old SQL tools that would help me access these.
Is it possible to use the .db file with a newer version?
Any help or guidance at all would be appreciated.
These are MY symptoms: (XP Pro, 32bit)
-Programs that access .mdb databases (aside from Access 2007 itself) can not get any data.
-Using the Data Sources in Visual Studio 2008 to connect to an MDB shows tables, but you can not query. you receive "Unknown Error" from the Microsoft JET Database Engine
-ArcCatalog can not read a personal geodatabase (mdb), after opening the database it has no feature classes within it
-Trying to bring up the properties of a User DSN "MS Access Database" in the ODBC Data Source Administrator returns error
"The setup routines for the Microsoft Access Driver (*.mdb, *.accdb) ODBC driver could not be found. Please reinstall the driver."
I attempted to reinstall latest MDAC (by setting it to compatibility mode of windows 2000) and latest JET driver. Reinstalled XP SP3.
Also tried a lot of regsvr32 gymnastics with the dao350.dll and dao360.dll, uninstalled the dao350, etc, etc. Nothing worked.
(Yes, I'm answering my own question, to record my solution)
I should also note, in addition to above, I couldn't use the SQL Native Client driver either.
In the registry, under HKLM\SOFTWARE\ODBC the \ODBC.INI branch contains any defined connections, and the \ODBCINST.INI contains records for the installed drivers.
I checked a similar development machine, and my ODBCINST.INI was missing A LOT of entries. I blame the ccleaner application that was recently used to clean up my system of junk.
After exporting the registry branch from the other computer, and importing over my existing keys, everything worked again.
Below are some of the core records, to generate a .reg script. You should get the full list from a similar machine to yours.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI]
[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Microsoft Access Driver (*.mdb)]
"UsageCount"=dword:00000002
"Driver"="C:\\WINDOWS\\system32\\odbcjt32.dll"
"Setup"="C:\\WINDOWS\\system32\\odbcjt32.dll"
"APILevel"="1"
"ConnectFunctions"="YYN"
"DriverODBCVer"="02.50"
"FileUsage"="2"
"FileExtns"="*.mdb"
"SQLLevel"="0"
[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Microsoft Access Driver (*.mdb, *.accdb)]
"UsageCount"=dword:00000003
"Driver"="C:\\PROGRA~1\\COMMON~1\\MICROS~1\\OFFICE12\\ACEODBC.DLL"
"Setup"="C:\\PROGRA~1\\COMMON~1\\MICROS~1\\OFFICE12\\ACEODBC.DLL"
"APILevel"="1"
"ConnectFunctions"="YYN"
"DriverODBCVer"="02.50"
"FileUsage"="2"
"FileExtns"="*.mdb,*.accdb"
"SQLLevel"="0"
[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Microsoft Excel Driver (*.xls)]
"UsageCount"=dword:00000002
"Driver"="C:\\WINDOWS\\system32\\odbcjt32.dll"
"Setup"="C:\\WINDOWS\\system32\\odexl32.dll"
"APILevel"="1"
"ConnectFunctions"="YYN"
"DriverODBCVer"="02.50"
"FileUsage"="1"
"FileExtns"="*.xls"
"SQLLevel"="0"
[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)]
"UsageCount"=dword:00000003
"Driver"="C:\\PROGRA~1\\COMMON~1\\MICROS~1\\OFFICE12\\ACEODBC.DLL"
"Setup"="C:\\PROGRA~1\\COMMON~1\\MICROS~1\\OFFICE12\\ACEODEXL.DLL"
"APILevel"="1"
"ConnectFunctions"="YYN"
"DriverODBCVer"="02.50"
"FileUsage"="2"
"FileExtns"="*.xls,*.xlsx, *.xlsb"
"SQLLevel"="0"
[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\SQL Native Client]
"UsageCount"=dword:00000001
"Driver"="c:\\WINDOWS\\system32\\sqlncli.dll"
"Setup"="c:\\WINDOWS\\system32\\sqlncli.dll"
"APILevel"="2"
"ConnectFunctions"="YYY"
"CPTimeout"="60"
"DriverODBCVer"="09.00"
"FileUsage"="0"
"SQLLevel"="1"
[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\SQL Server]
"UsageCount"=dword:00000002
"Driver"="C:\\WINDOWS\\system32\\SQLSRV32.dll"
"Setup"="C:\\WINDOWS\\system32\\sqlsrv32.dll"
"SQLLevel"="1"
"FileUsage"="0"
"DriverODBCVer"="03.50"
"ConnectFunctions"="YYY"
"APILevel"="2"
"CPTimeout"="60"