As part of the open-source software on PASE for i, MariaDB is available in the ibm repository. However, it seems like the MariaDB Connector/ODBC is not available.
Following the Building MariaDB Connector/ODBC From the Git Repository instructions does not work, since it appears that PASE is not supported. Forking it and modifying the source + build toolchain to work in PASE seems like a potential (but unattractive) option.
Is there a MySQL ODBC driver that can be used instead? Have I missed an available package? I also noticed that Zend / Seiden / etc have discussed using PHP with MySQL / MariaDB on PASE for i, how is PHP connecting to MariaDB in that case?
IBM does not currently provide an ODBC interface for connecting to MariaDB. Most high level languages provide a MySQL/MariaDB interface which does not require the client libraries (eg. PyMySQL).
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.
I'm starting a new PHP project with Symfony 3 and Doctrine 2 and I would like to use MariaDB 10.1 (or 10.0) instead of MySQL 5.7, but i cannot find if Doctrine (ORM) 2.5 supports MariaDB 10.1 and, if not, if there's any plan to support it in the future.
Does anyone know more? Known incompatibilities, future plans, etc.
For all intents and purposes, MariaDB 10 is identical to MySQL 5.6, so you should be good to go.
https://mariadb.com/kb/en/mariadb/mariadb-vs-mysql-compatibility/
MySQL 5.5 is compatible with MariaDB 5.5 and also in practice with MariaDB 10.0. What this means is that:
Data and table definition files (.frm) files are binary compatible.
See note below for an incompatibility with views!
All client APIs,
protocols and structs are identical.
All filenames, binaries, paths,
ports, sockets, and etc... should be the same.
All MySQL connectors
(PHP, Perl, Python, Java, .NET, MyODBC, Ruby, MySQL C connector etc)
work unchanged with MariaDB. There are some installation issues with
PHP5 that you should be aware of (a bug in how the old PHP5 client
checks library compatibility).
The mysql-client package also works
with MariaDB server.
The shared client library is binary compatible
with MySQL's client library.
This means that for most cases, you can just uninstall MySQL and install MariaDB and you are good to go.
Just beware that since Maria DB 10.0, not all features in MySQL 5.6 are available. A detailed comparison between MariaDB 10.1 and MySQL 5.7 can be found here:
https://mariadb.com/kb/en/mariadb/system-variable-differences-between-mariadb-101-and-mysql-57/
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 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.
I'm making installation script and I'm using ODBC, how can I automatically add a node to ODBC Data Sources.
Building installer with Visual Studio setup project, but I'm able to run any script for it.
Thank you.
1)
ODBC Data Sources are typically defined in registry entries - located at -
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI...... (DSNs on 32bit Windows or 64bit Windows)
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI...... (DSNs on 64bit Windows for 32bit Drivers)
That part of the registry contains the "System" DSNs - HKEY_CURRENT_USER contains "User" DSNs.
Of course, all drivers are different so there may be additional stuff required elsewhere too...
2)
You could also consider using File DSNs and ship the fie with the installer.
3)
You could also consider a DSN'less connection - but this would depend on how the ODBC application is coded.