Any ODBC experts here?

[rogue]

Originally Posted by Chris Card

Is unixODBC package installed too?

That's where /usr/bin/isql comes from according to

yum provides "*/isql"

unixODBC-2.2.14-12.fc14.x86_64 : A complete ODBC driver manager for Linux
Repo : fedora
Matched from:
Filename : /usr/bin/isql

It could be that /etc/odbc.ini and /etc/odbcinst.ini are unixODBC version instead of libiodbc.

These are questions for Paul.

[xilman]

Originally Posted by Chris Card

On Fedora isql comes from the unixODBC package, whereas iodbctest and iodbctestw come from a different package, libiodbc, so it's not too surprising that isql works and iodbtest doesn't; the config and drivers they expect are almost certainly different.

Which odbc library is ecmserver built against?

Chris

That may be the case, and I'm now searching the net for clues as to how they differ. If they differ, I'd expect it to be within the config files rather than the drivers. I'm far from being an expert, but this from http://www.iodbc.org/dataspace/iodbc...BC/ODBCDrivers "iODBC is purely an ODBC Driver Manager, not an ODBC driver. The following sites provide links to ODBC drivers for common databases." seems pretty unambiguous.

Paul

[Chris Card]

Originally Posted by xilman

That may be the case, and I'm now searching the net for clues as to how they differ. If they differ, I'd expect it to be within the config files rather than the drivers. I'm far from being an expert, but this from http://www.iodbc.org/dataspace/iodbc...BC/ODBCDrivers "iODBC is purely an ODBC Driver Manager, not an ODBC driver. The following sites provide links to ODBC drivers for common databases." seems pretty unambiguous.

Paul

The libiodbc package has some sample config files in it, on my system it puts them here:
/usr/share/doc/libiodbc-3.52.7/odbc.ini.sample
/usr/share/doc/libiodbc-3.52.7/odbcinst.ini.sample

Chris

[xilman]

Ok, progress!

First step was to give up on the standard PostgreSQL ODBC driver and load postgresql-odbcng

Sundry semi-random fiddling with /etc/odbc.ini /etc/odbcinst.ini and ~/.odbc.ini let me reach the point

[pcl@ra server]$ iodbctest "DSN=ECMnet;UID=ecmnet;PWD=pcl_ecmnet;"
iODBC Demonstration program
This program shows an interactive SQL processor
Driver Manager: 03.52.0709.0909
Driver: 00.99.0101 (libmodbc.so)

SQL>
Have a nice day.[pcl@ra server]$

which shows a successful connection! What's more, isql still works.


Unfortunately, ecmserver still fails thusly:

[pcl@ra server]$ ./ecmserver
[2011-08-04 17:40:56 BST] Connect to database failed: [iODBC][Driver Manager]ODBC Data Sources: cannot open shared object file: No such file or directory, native code=54
[pcl@ra server]$

but now we (Rogue and I) have something much more concrete to go on. Clearly, there's a mis-match between what ecmserver and iodbctest are trying to load. strace(1) to the rescue...

Paul

[xilman]

Success!

After much mucking around with strace(1) and tweaking of config files, I discovered a DSN wasn't necessary for ecmserver to work properly and that a driver entry in /etc/odbcinst.ini was sufficient. The server now connects.

Rogue should have an email by now which details the necessities so that he can update the documentation for the ECMnet server.

One day I may try to find out how to persuade the server to use a DNS but for the time being I'll use what works.

Thanks, everyone, for your assistance.

Paul

[rogue]

Originally Posted by xilman

Success!

After much mucking around with strace(1) and tweaking of config files, I discovered a DSN wasn't necessary for ecmserver to work properly and that a driver entry in /etc/odbcinst.ini was sufficient. The server now connects.

I find that interesting. I couldn't get the server to connect directly via the driver for PostgreSQL, but could with MySQL. It's my preference as it requires less configuration. I could only get PostgreSQL to connect via a dsn. In your case it is the opposite.

[rogue]

I took some time and discovered a couple of things today that shed some light on the mystery. First, Paul was having his problem with a DSN connection due to a code bug. It worked for me due because of how I configured the database.ini file. Second, I couldn't get psqlODBC (the PostgreSQL driver) to work because on OS X it is only 32-bits and I was building the server as a 64-bit application. Maybe they will fix it someday, but they haven't done so in more than two years. After recompiling the server as a 32-bit application, it worked flawlessly through the driver. Alas the driver I was using (OpenLink), which does support 64-bit apps, requires a license. Blech!

All of the connection problems are solved, but we have another issue with the database itself that we haven't licked yet. It works fine for me on both postgresql and mysql, so I suspect it is a difference between how we have the databases configured.

[Jeff Gilchrist]

So Paul, does that mean you will be upgrading the server sometime in the near future if you have things working?

[xilman]

Originally Posted by Jeff Gilchrist

So Paul, does that mean you will be upgrading the server sometime in the near future if you have things working?

Yes, but the operative words are "have things working".

Connections to the DB via ODBC are working well. Inserting data into it are problematic in that character data fail to be loaded by ecmserver for a reason which is presently unknown. Numeric data has no such problem. The DB itself appears to be working properly as measured by the success of other ways of accessing it and inserting/updating/deleting data.

I've a few ideas how to proceed but using the V3 ecmserver is likely to take a little time yet.

Paul