Thread: RE: [INTERFACES] not translating a query properly. . .
I would suggest either changing the protocol from 6.3 to 6.4 in the PostgreSQL ODBC driver. My other suggestion was to upgrade the PostgreSQL ODBC driver but it sounds like you have already done that. I believe the version you are seeing is the version of the ODBC driver and not the database server. I am assuming you are using PostgreSQL 6.4.2 or better. Booleans are another issue. Access97 treats boolean values as int2. It expects a -1 for true and 0 for false. PostgreSQL treats them as a character ('t' for true and 'f' for false). This means that the word TRUE in Access97 is a -1 and not the 't' that PostgreSQL is expecting. You have two choices the MS way or the PostgreSQL way. I converted all my booleans to int2 in PostgreSQL. This was not my first choice but I did not have to change all of the Access97 queries and code that interacted with boolean values. -----Original Message-----From: JT Kirkpatrick [SMTP:jt-kirkpatrick@mpsllc.com]Sent: Friday, April 30, 1999 10:51 AMTo: 'pgsql-interfaces@hub.org'Subject: [INTERFACES] not translating a query properly. . . here is my psqlodbc log -- it's short. i have two problems (or may just one). it still shows using version 6.3, but i completely removed 6.3 (in add/remove programs) and reinstalled 6.4. the other problem i am having is shown in it too -- i am in an access97 query sql view typing "select subnum from subs union all select vnum from vend;" (which works great from the psql prompt), but i am getting some kind of syntax error message. if you take the time to look into the file you'll also see another ongoing problem i am having with booleans in my queries (where i am trying to show all records that are 't' or =1 or any other way i try -- i just bombs). is there any reason why this query wouldn't run properly? i thought upgrading to the new version might help. . . jt << File: psqlodbc.log >>
I also had a problem with initdb creating 6.3 type databases after I had compiled and installed the pgsql 6.4 source. I had not completely removed all traces of 6.3. In particular, super-user postgres home address was RedHat style /var/lib whatever, and there were still some files there. After I deleted the postgres user and made sure everything was gone, then initdb worked properly. I went back to 6.3 anyway because I couldn't get pgaccess working in 6.4, and some other problems, and I was frazzled from the unaccustomed work of setting up from sources. Spoiled by rpm, I guess. I'll try again now that I've learned that there is an escape route. Fortunately for me this is all hobby, and I don't have anybody depending on my db. Incidentally, suse 5.2 has "wish" not in /usr/bin as specified in the stock pgaccess script. (I also fiddle with a suse distribution.) I solved this with a bash script that contained "wish -f <path to pgaccess>". Hugh Lawson Greensboro, North Carolina hglawson@nr.infi.net
Vital Signs: ------------ Database version: PostgreSQL 6.3.2 Alleged OS: UnixWare 2.1.2 Perl Version: Perl 5.004_04 DBI Module: DBI 0.91 DBD Driver: DBD-Pg 0.69 Gratuitous Whining: ------------------ This combination runs fine on Linux 2.0.30 (Slackware 3.4) and FreeBSD 2.2.7 and 2.2.8 (Perl 5.005) but, like so many other things, has trouble working properly on UnixWare... Symptoms: --------- The most rudimentary report that uses DBI::DBD-Pg to return a cursor select is failing with: dynamic linker: /usr/bin/perl: symbol not found: strncasecmp Debug Attempt: ------------- perl debug shows that the query is dying at line 101 of Pg.pm: 101: DBD::Pg::db::prepare(/opt/lib/perl5/site_perl/DBD/Pg.pm: 101): DBD::Pg::st_prepare($sth, $statement, @attribs) 102: or return undef; If I comment out the PAGER simply connect to the db I can do so without complaint. My $dbh->disconnect also exits without err. Any advice most appreciated (danke sehr, Edmund)... Tom ---- North Richmond Community Mental Health Center Thomas Good Information Systems Coordinator E-Mail: tomg@ { admin | q8 } .nrnet.org Phone: 718-354-5528 Fax: 718-354-5056 Empowered by PostgreSQL 6.3.2
Thomas Good wrote: > > Vital Signs: > ------------ > Database version: PostgreSQL 6.3.2 > Alleged OS: UnixWare 2.1.2 > Perl Version: Perl 5.004_04 > DBI Module: DBI 0.91 > DBD Driver: DBD-Pg 0.69 > > Gratuitous Whining: > ------------------ > This combination runs fine on Linux 2.0.30 (Slackware 3.4) and > FreeBSD 2.2.7 and 2.2.8 (Perl 5.005) but, like so many other things, > has trouble working properly on UnixWare... > > Symptoms: > --------- > The most rudimentary report that uses DBI::DBD-Pg to return a cursor > select is failing with: > > dynamic linker: /usr/bin/perl: symbol not found: strncasecmp > > Debug Attempt: > ------------- > perl debug shows that the query is dying at line 101 of Pg.pm: > > 101: DBD::Pg::db::prepare(/opt/lib/perl5/site_perl/DBD/Pg.pm: 101): > DBD::Pg::st_prepare($sth, $statement, @attribs) > 102: or return undef; > > If I comment out the PAGER simply connect to the db I can do so > without complaint. My $dbh->disconnect also exits without err. > > Any advice most appreciated (danke sehr, Edmund)... > Tom > ---- > North Richmond Community Mental Health Center > > Thomas Good Information Systems Coordinator > E-Mail: tomg@ { admin | q8 } .nrnet.org > Phone: 718-354-5528 > Fax: 718-354-5056 > > Empowered by PostgreSQL 6.3.2 in Pg.xs replace strncasecmp() by strncmp(). The check, in which strncasecmp is used, will not be as strict, as it should, but this is not critical. Edmund -- Edmund Mergl mailto:E.Mergl@bawue.de Im Haldenhau 9 http://www.bawue.de/~mergl 70565 Stuttgart fon: +49 711 747503 Germany