Having just got ConfigurationOfODBC working from Pharo Smalltalk, I had some trouble determining exactly how to get at the individual data items. So I thought I’d check out DBXTalk for comparison. DBXTalk is a lot more comprehensive solution leaveraging OpenDBX which includes its own ODBC interface along with several other backends. However all the ODBC connection examples I saw were for database servers with connection strings that were not of the “DSN” form that I think is required for Microsoft Access – so I ended up returning to ConfigurationOfODBC and resolving the issue above.
Yet I was most of the way through getting DBXTalk working, so I record my experience here for posterity. It is the “hack” version since to resolve library dependencies I simply copied everything next to virtual machine executable. I’ll look into resolving these more correctly later. So I…
- Created a new folder Pharo-1.3-13315-cog2522-dbxtalk and into it:
a. Extracted the “Contents” folder only from Pharo-1.3-13315-OneClick.zip
b. Extracted all files from cogwin_r2522.zip
c. Updated croquet.ini file with: ImageFile=Contents\Resources\pharo.image
- Ran croquet.exe and then:
World Menu > Monticello Browser.
- From the Monticello Browser opened:
then from a Workspace executed:
(ConfigurationOfOpenDBXDriver project version: #’stable’) load.
- From a Workspace found the required OpenDBX library to be 1.4.4 by executing:
- Extracted all nine files from http://linuxnetworks.de/opendbx/download/opendbx-1.4.4_win32.zip into folder Pharo-1.3-13315-cog2522-dbxtalk
- From a DBXTalk developer I asked which version of PostgreSQL to try, and the prompt response came back as 8.3. I installed the current version at this time (postgresql-8.3.17-1-windows.exe) choosing all the defaults.
- Now possibly step 3 is made redundant by the following, but this post is a record of what I actually did.
In Monticello Browser I opened repository:
then in a Workspace I executed:
(ConfigurationOfGlorpDBX project version: #’stable’) load.
which left the following message in Transcript
IMPORTANT FOR GLORP AND OpenDBXDriver DRIVER
In order to run sucessfully Glorp tests you should need to change the database connection settings used by them. To do this, change the following methods:
After doing this all Glorps tests must be green.
Evaluated -> GlorpOpenDBXDriver >> postLoadGlorpDriverDBXTalkPharo
Looking at GlorpDatabaseLoginResource>>defaultPostgreSQLLocalLogin shows:
“To set the default database login to PostgreSQL, execute the following statement.”
^DefaultLogin := (Login new)
database: PostgreSQLPlatform new;
Now rather than changing these connection settings, for a first attempt I thought it might go easier the other way making the database match the tests, so…
- From the Windows Start Menu ran pgAdminIII.
- From pgAdminIII created a new user sodbxtest:
Servers > PostgreSQL 8.3 (localhost:5432) >Login Roles > New Login Role.
with the widest privileges possible.
- From pgAdminIII created database sodbxtest:
Servers > PostgreSQL 8.3 (localhost:5432) > Databases >> New Database
Privileges=ALL, Role Public
- Then for later comparison I checked that the number of tables in this new database is zero: Servers > PostgreSQL 8.3 (localhost:5432) > Databases > sodbxtest > schemas > public > Tables
- Now “the hack” (since I was in a rush and would have needed to log out and back in as Admin to adjust the search paths.)
In Pharo I ran some Glorp Tests and got an error “could not find libpq.dll.” After finding this file in folder PostgresSQL/8.3/libs, rather than properly resolving the lookup, the quick fix was copying everything from that folder next to the virtual machine in folder Pharo-1.3-13315-cog2522-dbxtalk. A subsequent error “could not find ssleay32.dll” was fixed similarly by copying the contents of folder PostgresSQL/8.3/bin next to the virtual machine.
- Then in Pharo from World Menu > Test Runner all 823 tests for GlorpTests-Models, GlorpTests-Database & GlorpTest are successful.
In addition, if I recheck the number of tables noted in Step 14 and find there are now 75 tables – full of data.
Excluded from this are GlorpTests-DatabaseTypes, GlorpTests-Extras, GlorpOpenDBXDriverTests since they seem to cycle through testing databases that I don’t have installed – in particular OCI.dll for Oracle.
One small annoyance is that once a “missing OCI.dll” error occurs, it continues to occur even when the previously successful tests are rerun. This remains until reset by: GlorpDatabaseLoginResource defaultPostgreSQLLocalLogin.
So this is a good result and I’ll be glad to further DBXTalk later on. However for now, for my current requirements (a one-time one-way import from an mdb file into Pharo) I think that ConfigurationOfODBC is more suitable.