[Cuis-dev] ODBC error

[Jon Raiford]

I’m glad we were able to get it working. One last thing about the change to the ODBC package. Replacing “ODBCRow new: columns size” with just “ODBCRow new” should work both in the stable release and the current dev rolling release. I would suggest making the change, saving the package, and creating a pull request to fix the issue at the source.  By the way, I did the same with the launch script and it was merged. Cuis will now work with the Homebrew lib directory by default.

Jon

From: Mark Volkmann <r.mark.volkmann at gmail.com>
Date: Saturday, October 26, 2024 at 5:38 PM
To: Jon Raiford <raiford at labware.com>
Cc: Discussion of Cuis Smalltalk <cuis-dev at lists.cuis.st>
Subject: Re: [Cuis-dev] ODBC error
SUCCESS! Many thanks to Jon Raiford for supplying lots of tips that eventually resulted in me being able to access a SQLite database from Cuis Smalltalk!

I have documented everything I learned about this at https://mvolkmann.github.io/blog/topics/#/blog/smalltalk/50-databases/<https://mvolkmann.github.io/blog/topics/#/blog/smalltalk/50-databases/>.
I welcome any corrections and suggested improvements.

In particular, see the part near the beginning that describes a minor change that is required in the ODBCResultSet fetchRow method.
I am using the Cuis rolling release. It's possible that this change is not needed when using the stable release.

On Thu, Oct 24, 2024 at 12:46 PM Mark Volkmann <r.mark.volkmann at gmail.com<mailto:r.mark.volkmann at gmail.com>> wrote:
Thanks so much for looking into this! When I run that command I get the following:

/usr/local/lib/libodbc.dylib:
    /usr/local/opt/unixodbc/lib/libodbc.2.dylib (compatibility version 3.0.0, current version 3.0.0)
    /usr/local/opt/libtool/lib/libltdl.7.dylib (compatibility version 11.0.0, current version 11.2.0)
    /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.0.0)

On Thu, Oct 24, 2024 at 12:19 PM Jon Raiford <raiford at labware.com<mailto:raiford at labware.com>> wrote:
I had a quick look at this on my M1 MBP.

I did the following:

* git clone Cuis-Smalltalk-Dev
* git clone Cuis DatabaseSupport
* modified the launch script as you described below
* run the script: ./RunCuisOnMacTerminal.sh
* open a workspace
* doIt: Feature require: ‘ODBC’
* printIt: ODBCConnection new sqlAllocEnv   => a SQLHENV .

If I remove the DYLD_LIBRARY_PATH from the launch script then I get the module not found error.

Based on your info below, your homebrew lib path is /usr/local/lib and libodbc.dylib exists in the directory, which is the moduleName defined in ODBCLibrary class>>moduleName.

That all looks correct.

What do you get if you run this from the command line?
%  otool -L /usr/local/lib/libodbc.dylib


Jon

From: Mark Volkmann <r.mark.volkmann at gmail.com<mailto:r.mark.volkmann at gmail.com>>
Date: Tuesday, October 22, 2024 at 7:32 PM
To: Jon Raiford <raiford at labware.com<mailto:raiford at labware.com>>
Cc: Discussion of Cuis Smalltalk <cuis-dev at lists.cuis.st<mailto:cuis-dev at lists.cuis.st>>
Subject: Re: [Cuis-dev] ODBC error
See my replies inline below.

On Tue, Oct 22, 2024 at 3:56 PM Jon Raiford <raiford at labware.com<mailto:raiford at labware.com>> wrote:
What exactly do you mean by not working? Is it not able to open the shared library? Or it is not able to connect to a database? The first thing that happens is allocating the environment by either calling SQLAllocHandle() (current versions of ODBC) or SQLAllocEnv() (old versions of ODBC).

I'll describe what I have tried below, but I'm not claiming that I have finished investigating this. It's just my progress so far.

1. Run the Homebrew command "brew install unixodbc" to install the ODBC dynamic library.

That gives me the following files in /usr/local/lib:

libodbc.2.dylib
libodbc.a
libodbc.dylib
libodbccr.2.dylib
libodbccr.a
libodbccr.dylib
libodbcinst.2.dylib
libodbcinst.a
libodbcinst.dylib

2. Run the command "brew install sqliteodbc" to install the SQLite-specific shared library.

That gives me the file /usr/local/lib/libsqlite3odbc.dylib
I'm not certain I need this file, but I reference it below.

3. Create the file /usr/local/etc/odbc.ini containing the following which refers to a dynamic library that exists and SQLite database file that exists.

[TodoDSN]
Description = SQLite ODBC Driver
Driver = /usr/local/lib/libsqlite3odbc.dylib
Database = /Users/volkmannm/Documents/dev/lang/smalltalk/Cuis-Smalltalk-Dev-UserFiles/todos.db
Timeout = 2000
4. Clone the GitHub repository at https://github.com/Cuis-Smalltalk/DatabaseSupport.git<https://github.com/Cuis-Smalltalk/DatabaseSupport.git> into the same directory that holds the Cuis-Smalltalk-Dev directory.

5. Change the file RunCuisOnMacTerminal.sh to the following:

export DYLD_LIBRARY_PATH="$(brew --prefix)/lib:${DYLD_LIBRARY_PATH}"
./CuisVM.app/Contents/MacOS/Squeak CuisImage/Cuis?.?-????.image -u

5. Run that script.

6. Open a "File List", navigate to the DatabaseSupport directory, select ODBC.pck.st<http://ODBC.pck.st>, and click "install package".

7. Open a Workspace and evaluate the following:

conn := ODBCConnection dsn: 'TodoDSN' user: '' password: ''.
This gives the error "External module not found".  See the attached screenshot.

I don’t have an easy way to test that old ODBC code at the moment, but it should be easy enough to find the library class. It is a subclass of ExternalLibrary. From there you can find the alloc call and walk back through senders to figure out how it is called. From there you can see the order things are called.

I only see one subclass of ExternalLibrary and it is ODBCLibrary. I think the alloc call you are referring to is the one in the attached screenshot, but I haven't been able to determine which external module it can't find. The line that fails is:

<cdecl: int16 'SQLAllocEnv' (SQLHENV*)>

One annoying thing to note is that you cannot use the debugger to step through an FFI call. It will always say there is an invalid module or something like that. I’ve spoken to Eliot about this and we should be able to get it fixed at some point. But for now just put a self halt after the call and then look at the return code.

Arranging a call would be difficult at the moment. I’m already burning the candle at both ends so not much time unfortunately.

I understand.

--
R. Mark Volkmann
Object Computing, Inc.


--
R. Mark Volkmann
Object Computing, Inc.


--
R. Mark Volkmann
Object Computing, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20241027/1d17eac2/attachment-0001.htm>