Thread: unixODBC (again)
Hi, Having seen that the driver I distribute doesn't work against 7.1 Beta 4, and not wanting to continue the split between the two versions, I have tried to get the driver in the beta working with unixODBC, but I have come against a couple of problems, one a show stopper. First let me say that I want to stop the split between the version, If I can just point people to your distribution, thats fine by me, but it needs to work :-). I am not trying to get you to standardise on unixODBC, just to provide the option. Initially I had to link my system odbc.ini to a user odbc, because the driver looks in the home account. This would be SO much better if there was a build option to link with libodbcini.so, not saying it should be the default, just that the option would be great. After this, it still didn't find the entries, I fould the problem was the code couldn't handle spaces in the ini file, so [dsn] Servername=fred works, but [dsn] Servername = fred doesn't. Not a major point, but again the ini lib would fix this. Then having sorted this out, I get a core dump, that I have traced to CC_lookup_pg_version, the code did CC_lookup_pg_version(ConnectionClass *self) { HSTMT hstmt; StatementClass *stmt; RETCODE result; char *szVersion= "0.0"; static char *func = "CC_lookup_pg_version"; Then later did a sprintf( szVersion... ); This seems to be trying to write into, what the compiler is marking as read only storage. A quick change to CC_lookup_pg_version(ConnectionClass *self) { HSTMT hstmt; StatementClass *stmt; RETCODE result; char szVersion[3 ]; static char *func = "CC_lookup_pg_version"; strcpy( szVersion, "0.0" ); Fixes the problem, and it connects. I will continue testing, with some apps and see how it gets on -- Nick Gorham Easysoft Ltd
Nick Gorham writes: > First let me say that I want to stop the split between the version, If > I can just point people to your distribution, thats fine by me, but it > needs to work :-). I am not trying to get you to standardise on > unixODBC, just to provide the option. This is nice, but it contradicts your earlier patches, because it would create a circular dependency: You need PostgreSQL's ODBC to get unixODBC set up, but you need [--with-]unixODBC to get PostgreSQL prepared for unixODBC. That said if there are improvements in your version, why not send patches to improve our version, rather than providing patches to link our version against your version? That doesn't make sense to me. I'm not trying to annoy you, I'm just wondering. > Initially I had to link my system odbc.ini to a user odbc, because the > driver looks in the home account. This would be SO much better if there > was a build option to link with libodbcini.so, not saying it should be > the default, just that the option would be great. Why not have us include that libodbcini.so in our distribution? Certainly, no one would get upset if we had better config/ini file parsing. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Nick Gorham wrote: > > Then having sorted this out, I get a core dump, that I have traced to > CC_lookup_pg_version, the code did > > CC_lookup_pg_version(ConnectionClass *self) > { > HSTMT hstmt; > StatementClass *stmt; > RETCODE result; > char *szVersion = "0.0"; > static char *func = "CC_lookup_pg_version"; > > Then later did a > > sprintf( szVersion... ); > > This seems to be trying to write into, what the compiler is marking as > read only storage. A quick change to > You are right, it seems a misuse of char *. > CC_lookup_pg_version(ConnectionClass *self) > { > HSTMT hstmt; > StatementClass *stmt; > RETCODE result; > char szVersion[ 3 ]; > static char *func = "CC_lookup_pg_version"; > > strcpy( szVersion, "0.0" ); > szVersion[3] seems too short. I would increase the length and commit it soon. Regards, Hiroshi Inoue