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)