Обсуждение: 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