Any ODBC experts here?

[xilman]

I'm hitting problems with connecting to a PostgreSQL database through ODBC. Everything is running on a single 64-bit Fedora 15 system, so there's no worries about network configs, firewalls, etc. The ultimate aim is to get V3 ECMnet server running here but, with one exception, the ODBC mechanism isn't working. The exception is that the "isql" tester program works perfectly. None of iodbctest, iodbctestw and ecmserver make a successful connection. Non-ODBC connections using psql work perfectly.

Rogue has been helping me but his experience with ODBC lies in systems other than Fedora. Is there anyone else on the forum who may be able to give assistance?

I will, of course, provide as much information as I can on request, including a ssh-accessible account if necessary.

Thanks,
Paul

[chalsall]

Originally Posted by xilman

I'm hitting problems with connecting to a PostgreSQL database through ODBC. Everything is running on a single 64-bit Fedora 15 system, so there's no worries about network configs, firewalls, etc.

I haven't dealt with ODBC for a very long time, but I do have some experience debugging network and server problems under Linux...

Some suggestions:

1. Do you have SELinux enabled? If so, in enforcing or permissive mode?

1.1. SELinux can cause problems beyond simple Firewall rules -- it can prevent software within a machine from working if it's doing "unusual" things.

2. If you can, have you tried having the server on one box, and the client on another?

2.1. tcpdump and/or Wireshark can be your best friend, letting you "sniff the wire".

3. What do (all) your logs tell you?

...for what that is worth.

[rogue]

Originally Posted by xilman

I'm hitting problems with connecting to a PostgreSQL database through ODBC. Everything is running on a single 64-bit Fedora 15 system, so there's no worries about network configs, firewalls, etc. The ultimate aim is to get V3 ECMnet server running here but, with one exception, the ODBC mechanism isn't working. The exception is that the "isql" tester program works perfectly. None of iodbctest, iodbctestw and ecmserver make a successful connection. Non-ODBC connections using psql work perfectly.

Question, is isql using the odbc connection? Do you know how it is building the connection string?

[Chris Card]

Originally Posted by xilman

I'm hitting problems with connecting to a PostgreSQL database through ODBC. Everything is running on a single 64-bit Fedora 15 system, so there's no worries about network configs, firewalls, etc. The ultimate aim is to get V3 ECMnet server running here but, with one exception, the ODBC mechanism isn't working. The exception is that the "isql" tester program works perfectly. None of iodbctest, iodbctestw and ecmserver make a successful connection. Non-ODBC connections using psql work perfectly.

Rogue has been helping me but his experience with ODBC lies in systems other than Fedora. Is there anyone else on the forum who may be able to give assistance?

I will, of course, provide as much information as I can on request, including a ssh-accessible account if necessary.

Thanks,
Paul

I've had ODBC working to mysql on Centos 5.4, which should be similar.

I second the suggestion of using tcpdump or wireshark to see what's going over the wire.

Also you could try running the odbc client under strace to see what it's trying to do - possibly there's a problem loading a shared library or something like that.

Chris

[rogue]

Originally Posted by Chris Card

I've had ODBC working to mysql on Centos 5.4, which should be similar.

I second the suggestion of using tcpdump or wireshark to see what's going over the wire.

Also you could try running the odbc client under strace to see what it's trying to do - possibly there's a problem loading a shared library or something like that.

Although MySQL is an option for Paul (one that I use as well), he prefers PostgreSQL. I have only had success using PostgreSQL connecting via a DSN. ODBC allows one to connect via a driver only, which works fine with MySQL, but not with PostgreSQL.

[chalsall]

Originally Posted by rogue

Although MySQL is an option for Paul (one that I use as well), he prefers PostgreSQL. I have only had success using PostgreSQL connecting via a DSN. ODBC allows one to connect via a driver only, which works fine with MySQL, but not with PostgreSQL.

So this is where you have to tell your client "your preferred solution (PostgreSQL) isn't working. But this one (MySQL) is. Would you like me to implement a working solution for you, or would you like me to spend a great deal of time (and your money) debugging your preferred solution.

As an aside, I'll still bet a glass of ale that the problem is SELinux....

[chalsall]

Originally Posted by Chris Card

Also you could try running the odbc client under strace to see what it's trying to do - possibly there's a problem loading a shared library or something like that.

I second that suggestion.

[rogue]

Originally Posted by chalsall

As an aside, I'll still bet a glass of ale that the problem is SELinux....

That is possible, but we don't know yet. I am able to run my software (ECMNet and PRPNet) against MySQL and PostgreSQL on both Windows and OS X.

[chalsall]

Originally Posted by rogue

That is possible, but we don't know yet. I am able to run my software (ECMNet and PRPNet) against MySQL and PostgreSQL on both Windows and OS X.

rogue... Based on your above, just how much experience have you had in Linux?

[rogue]

Originally Posted by chalsall

rogue... Based on your above, just how much experience have you had in Linux?

I haven't worked with ODBC drivers on Linux at all.

Note that many people run PRPNet on Linux using it with MySQL. Nobody has reported problems like this to me, although for those who have had problems, it always comes down to a missing library or permission or incorrect configuration.

[chalsall]

Originally Posted by rogue

I haven't worked with ODBC drivers on Linux at all.

Note that many people run PRPNet on Linux using it with MySQL. Nobody has reported problems like this to me, although for those who have had problems, it always comes down to a missing library or permission or incorrect configuration.

So, then, I would suggest strongly that you take Chris Card's above advice, and run the client (and possibly the server) under strace.

If you can understand the output, it will tell you *exactly* where the client runs into problems.

(Although, if I might add, it might help you if you have a working solution under the same OS environment (but a different DB target), against which you can meta "diff" the results.)