Intersolv/ODBC

[Dave Yeo]

I built unixodbc many years ago, but our toolset wasn't as mature back then, so I'm not sure the modules ever actually worked. Happy to have another look at it.

I just tried, libtoolize went into a Perl loop and failed.

[Jan-Erik Lärka]

This is what I had in mind for a GUI Admin tool I started to work on... if someone would like to contribute how to open settings for the drivers and handle settings etc.

[Per E. Johannessen]

I built unixodbc many years ago, but our toolset wasn't as mature back then, so I'm not sure the modules ever actually worked. Happy to have another look at it.

That was back in 2015 and I still have some notes about the project. Part of the problem seemed to be lack of source code for odbc drivers, and the one supplied with unixodbc 010 had some bugs. What about the one that is included with OpenOffice or iODBC?

[Paul Smedley]

I built unixodbc many years ago, but our toolset wasn't as mature back then, so I'm not sure the modules ever actually worked. Happy to have another look at it.

I just tried, libtoolize went into a Perl loop and failed.

Yep, me too. Perhaps I'll try it with my updated Perl....

[Dave Yeo]

This is what I had in mind for a GUI Admin tool I started to work on... if someone would like to contribute how to open settings for the drivers and handle settings etc.

There's a Qt4/5 (I think Qt4 is stable) GUI admin tool for unixodbc as well.

[Jan-Erik Lärka]

There's a Qt4/5 (I think Qt4 is stable) GUI admin tool for unixodbc as well.

Yes, I've seen it for quite some time now.
The attached file was modeled after the text mode instodbc as of unixodbc version 2.3.4, though use rexx on OS/2 and can therefore be enhanced and translated easily. (English and Swedish included)

[Paul Smedley]

I built unixodbc many years ago, but our toolset wasn't as mature back then, so I'm not sure the modules ever actually worked. Happy to have another look at it.

I just tried, libtoolize went into a Perl loop and failed.

Yep, me too. Perhaps I'll try it with my updated Perl....

Updating Perl didn't help.....

[Doug Clark]

This is what I had in mind for a GUI Admin tool I started to work on... if someone would like to contribute how to open settings for the drivers and handle settings etc.

It looks nice Jan-Erik.

According to the ODBC documentation the function SQLConfigDataSource() is used to call the driver's setup routine, presumably including any dialog box(es) the driver needs to display to get info from the user to set up the datasource. 

The header files in the ODBC SDK specify calling convention for all functions in the SDK.

The UnixODBC driver manager that I got off of the web reports itself as version 3.52.  However I believe that UnixODBC at that time did not support fileDSNs, so neither does the OS/2 port.  The lack of FileDSNs isn't a big loss, in my opinion, since a FileDSN is just a DSN where the configuration information is stored in a separate disk file instead of being stored in ODBC.INI. Arca Noae may feel differently with their corporate customers: the idea of a FileDSN is the file can be created by a network administrator and stored on a file server, instead of requiring each user to create their own DSN on their own machines through the ODBC administator.

Also the concept of User and System DSNs doesn't make sense in OS/2 since OS/2 is really a single user system. That is why the Intersolv administrator only shows User DSN.  (System DSNs are available to all users of a machine, User DSNs are available only to a specific user.)


If Paul Smedley wants to pull the latest sources for UnixODBC and compile them for OS/2 that would be GREAT.  But please keep the following issues in mind.

#1 The format of the ODBC.INI (and possibly ODBCINST.INI - I just don't remember right now) produced by Intersolv and by UnixODBC are slightly different.  I don't think the linux world had an installed Intersolv base they needed to conform to and we do on OS/2.  It would be nice if the new UnixODBC would produce ODBC.INI and ODBCINST.INI files that match the format used by Intersolv.  That way a user could use those files (and the drivers) with either UnixODBC or Intersolv.  This is because of #2

#2 There are users that purchased licensed versions of Intersolv drivers and use those with OS/2 applications.  For example Lotus Smart Suite bundled a complete set of licensed drivers.  Unfortunately the licensing for Lotus Smart Suite limits the use of those drivers to Smart Suite applications,  It appears the application calls a special function (probably in the Intersolv driver manager) that checks the licensing information while connecting.  If that function cannot be implemented in the UnixODBC port then the user would need to switch between Intersolv ODBC and UnixODBC in order to continue to use their licensed drivers.  The function that is called is mentioned in one of the readmes for VisualAge Basic - sorry I don't remember more details right now.

[Jan-Erik Lärka]

According to the ODBC documentation the function SQLConfigDataSource() is used to call the driver's setup routine, presumably including any dialog box(es) the driver needs to display to get info from the user to set up the datasource. 

The header files in the ODBC SDK specify calling convention for all functions in the SDK.

The image posted come from the app I started to design with VX-Rexx as can be seen on the icon of the window in front.
If one would go ahead there, one need a support library for rexx to call SQLConfigDataSource(...), but would would need one to query the driver itself as well, but a rexx library provide greeat flexability, yet power and should be easy to assemble.

Wrote some java code that load jdbc4 drivers, list them and their settings that could be used to set thing up.
Would be much gained if the different jdbc drivers would appear just like individual odbc driver rows to avoid special manager window for those.

At the same time I began to tinker with ideas on how to create ODBC-to-JDBC-bridge, but the problem with floating point exceptions made me stop. I do have C/C++ code now that can load jvm.dll and use java functions... so BSF4ooRexx and ODBC-to-JDBC should be possible as long as one avoid debugging. But someone else has to come up with the code to shuffle data, queries etc.

The UnixODBC driver manager that I got off of the web reports itself as version 3.52.  However I believe that UnixODBC at that time did not support fileDSNs, so neither does the OS/2 port.  The lack of FileDSNs isn't a big loss, in my opinion, since a FileDSN is just a DSN where the configuration information is stored in a separate disk file instead of being stored in ODBC.INI. Arca Noae may feel differently with their corporate customers: the idea of a FileDSN is the file can be created by a network administrator and stored on a file server, instead of requiring each user to create their own DSN on their own machines through the ODBC administator.

Also the concept of User and System DSNs doesn't make sense in OS/2 since OS/2 is really a single user system. That is why the Intersolv administrator only shows User DSN.  (System DSNs are available to all users of a machine, User DSNs are available only to a specific user.)

If Paul Smedley wants to pull the latest sources for UnixODBC and compile them for OS/2 that would be GREAT.  But please keep the following issues in mind.

That is a very important part you mention below

#1 The format of the ODBC.INI (and possibly ODBCINST.INI - I just don't remember right now) produced by Intersolv and by UnixODBC are slightly different.  I don't think the linux world had an installed Intersolv base they needed to conform to and we do on OS/2.  It would be nice if the new UnixODBC would produce ODBC.INI and ODBCINST.INI files that match the format used by Intersolv.  That way a user could use those files (and the drivers) with either UnixODBC or Intersolv.  This is because of #2

How about the Q+E drivers with DBExpert?

#2 There are users that purchased licensed versions of Intersolv drivers and use those with OS/2 applications.  For example Lotus Smart Suite bundled a complete set of licensed drivers.  Unfortunately the licensing for Lotus Smart Suite limits the use of those drivers to Smart Suite applications,  It appears the application calls a special function (probably in the Intersolv driver manager) that checks the licensing information while connecting.  If that function cannot be implemented in the UnixODBC port then the user would need to switch between Intersolv ODBC and UnixODBC in order to continue to use their licensed drivers.  The function that is called is mentioned in one of the readmes for VisualAge Basic - sorry I don't remember more details right now.

rexx/ooRexx 5.0 support (something like in unixodbc 010)

[Per E. Johannessen]

Does anyone if the odbc driver included with OpenOffice or the one in iODBC could be used?

[Jan-Erik Lärka]

I have to use a patched version of the Apache OpenOffice odbc.dll to list selectable datasources... but then again, base refuse to actually reinitialize the connection once one reopen any .odb-file.

[Per E. Johannessen]

OK, but aren't the sources available? Perhaps someone could do necessary modifications to make it work with other programs than OpenOffice?