I am trying to get the mapviewer running. Whatever I do I get either one of these error messages:
Data source cannot be created : C:\oraclexe\app\oracle\product\11.2.0\server
\bin\ocijdbc10.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
Data source cannot be created : C:\oraclexe\app\oracle\product\11.2.0\server
\bin\ocijdbc10.dll: %1 is not a valid Win32 application
I understand that it has to do with the jdk/dll bit version. However, as I have tried all possibilities can someone please suggest a solution which I may have overlooked? Thanks.
It looks like you are using the OCI driver. Try using the thin JDBC driver instead. This is platform agnostic.
http://www.orafaq.com/wiki/JDBC
The OCI driver works with the installed Oracle client and therefore requires native DLLs. The thin driver is pure Java.
Related
According to this, if I read this correctly, Tableau desktop on a Mac M1 cannot use the snowflake ODBC driver. Is this still true? Generally, my ODBC driver for snowflake works.
PS:
#aek I still get:
in Tableau. I installed:
2.25.3 snowflake_odbc_mac-2.25.3.dmg mac64
and configured odbc.ini files and everything appears to work fine in:
If I run (as suggested here):
"/Library/Application Support/iODBC/bin/iodbctest"
I get:
1: SQLDriverConnect = [iODBC][Driver Manager]dlopen(/opt/snowflake/snowflakeodbc/lib/universal/libSnowflake.dylib, 0x0006): tried: '/opt/snowflake/snowflakeodbc/lib/universal/libSnowflake.dylib' (fat file, but missing compatible architecture (have 'i386,x86_64', need 'arm64')) (0) SQLSTATE=00000
2: SQLDriverConnect = [iODBC][Driver Manager]Specified driver could not be loaded (0) SQLSTATE=IM003
Is there anything I can/have to do that Tableau recognised the driver?
Yes, this is still true (for v. 2022.3). According to the spec, Tableau Desktop still works in emulation mode. The application and driver must have the same architecture. So for Tableau Desktop, you need to use the Mac64 version of the driver, as the article suggests.
Edit: How to make it working.
The native Snowflake connector in Tableau will try to use the "OS architecture appropriate" driver. Which is not the case for an x64 app running on ARM. Therefore, when configuring the connection, instead of choosing Snowflake from the list, you should use Other Databases (ODBC) and select the Snowflake DSN configured with the Mac64 version of the driver accordingly to the doc.
we are currently trying to run asp.net core 2.0 (latest preview) on Linux arm (Raspberry Pi - Ubuntu Mate) and we were able to solve almost all the issues so application works very well.
Not we are trying to run it with SQL Db (Sqlite) and on Windows, everything works fine, we can connect and read the DB but on the linux, we are getting following error:
System.DllNotfoundException: Unable to load DLL 'e_sqlite3': The specified module or one of its dependencies could not be found. (Exception from HRESULT: 0x8007007E).
I think I already tried everything, installed sqlite on linux, but nothing helped.
Any idea what might be wrong?
Thanks a lot
Rado
i changed the library that I used to connect to sqlite to this one
https://www.nuget.org/packages/sqlite-net-pcl/
and then (and not sure why), on linux, i had to take their implementation of SQLite.cs and manually add it to the project.
So for Linux, i had to have that CS included and for windows, i just excluded it so the one which was part of DLL works. Didn't do more investigation, but it works on Windows and Linux as well.
If you need more help just let me know.
https://github.com/oysteinkrog/SQLite.Net-PCL
This file:
https://github.com/praeclarum/sqlite-net/blob/master/src/SQLite.cs
Thanks
Rado
I think we'll have to wait, the issue isn't closed.
UPDATE:
this issue is closed and launched new version. You only need install the last version 1.1.8 of the package SQLitePCLRaw.bundle_green and SQLite in ARM works fine.
I am having the same issue and I after some investigation I think this happens because e_sqlite3.dll for ARM is not (yet) included the SQLitePCLRaw.bundle_green package.
This package contains the dll for different architectures but linux-arm is not yet mentioned in the dependencies (linux, osx and v110xp (win7) are).
We probably have to wait until the .NET Core ARM team adds it properly...
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.
if i try to run my qt application on windows 7, the console print:
QPSQL driver not loaded ... available driver:...QPSQL...
After that, i've tried to include the following paths to the windows path variable
C:\psql32\bin;C:\psql32\include;C:\psql32\lib;
The application can connect to the psql db and all works fine. How can i fix this problem, without to install the psql software on all pc's. ?
Best regards, chris.
Usually you don't need to use the drivers from Postgres. At least in the version I use (commercial, 4.8.4, Win)
Qt provides the drivers in the directory <QTDIR>\plugins\sqldrivers.
When the application runs on the computer, where Qt is installed, nothing should be done explicitly - Qt should find the drivers.
When the application is deployed on a computer without Qt-installation, I copy release versions of the files found in <QTDIR>\plugins to <MyAppExeDir>\plugins.
Besides Sql drivers, same problem could apply also to jpeg an other pluggable components.
P.S.:
Make sure, not to mix Qt-dlls from one computer with Qt-plugins from other computer, even if the versions are the same.
I'm dealing with an issue that has arisen for an application I've been working on which connects to a Access file via JDBC-ODBC. On other Windows platforms, this issue hasn't been encountered, but on Windows 7 64-bit boxes, attempting to connect with DSN-less connection strings return:
java.sql.SQLException: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
Multiple variations on the string have been attempted, but all of them have returned the same error. Here's how it currently tries to connect:
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
StringBuffer databaseConnectionString;
if (SystemUtils.IS_OS_WINDOWS_7) {
databaseConnectionString = new StringBuffer("jdbc:odbc:DRIVER=Microsoft Access Driver (*.mdb, *.accdb);DBQ=");
databaseConnectionString.append(databaseFile);
} else {
databaseConnectionString = new StringBuffer("jdbc:odbc:Driver={Microsoft Access Driver (*.mdb)};DBQ=");
databaseConnectionString.append(databaseFile);
databaseConnectionString.append(";DriverID=22;READONLY=false}");
}
Examining the driver in the 32-bit ODBC Data Source Admin confirms that the drivers are present. However, when regedt32.exe is used to examine ODBC drivers (HKEY_LOCAL_MACHINE/SOFTWARE/ODBC/ODBCINST.INI/ODBC Drivers), none of them appear.
Can anyone help to shed some light on this?
I found the problem was that I was running the program in 64-bit Java. Although I have yet to successfully have the program detect if it's running in 32-bit or 64-bit Java, I have solved the solution by installing a 32-bit Java runtime environment and using a .bat file that reads as follows:
#echo off
"C:\Program Files (x86)\Java\jre6\bin\java" -D32 -Xmx1024m -jar programName.jar
Thanks for the help!
This was a difficult challenge given the paucity of meaningful error messages from JAVA or MS's ODBC driver. The answers above about down selecting to 32bit Java and MS Access drivers (using AccessDatabaseEngine.exe from MS) did work but cost a significant penalty (about 30%) in processing other actions compared to using 64bit Java. I was unwilling to pay this price so I installed 64bit Java (in conjunction with 32bit, both in a separate directory c:\Java\32 or 64). This latter directory issue was important for me since I was using Apache Geronimo and it would not start if Java was installed in Program Files (x86)... as the (x86) seemed to kill its batch file parsing. I then uninstalled 32bit MS Access and installed 64bit MS Access (AccessDatabaseEngine_x64.exe). Finally, it worked with both higher speed and MDB connection.