R: [INTERFACES] Re: Possible bugs in ODBC driver - Mailing list pgsql-interfaces

Byron,

1) I do know that Access is not affected by this problem. BTW it is based
on DAO.
Borland Products are affected and, like Access and other MS products are
based on an unified engine, called BDE.
2) Unfortunately I don't think to be the only one with problems since I saw
some problem reports on the mailing list posted by other Borland products
users (if I remember well...). I know, BDE sometimes is a dog, but we have
to live with it as we have to live with DAO.
3) I copied all the log file, and the BDE does not generate the disconnect
statement you suggest.
4) The buffer too small problem is evident only on those big schema tables.
No probs on smaller ones. The duplicate table names is present in all
databases.
5) I downloaded the debug version of the DLL, replaced the old version (and
saved a backup copy...) and turned on the debugging option. Here there are
the results of the same query I ran this morning (BTW the ASPRO medicinal
variants are present in 7 rows of 300.000 records):

BDE error displayed: Record size is too big for table. Error code (don't
know if it is originated by ODBC or by BDE: 9477 plus two hex values in two
other edit boxes: $25 and $5

Contents of psqlodbc.log:

conn=50202748, SQLDriverConnect(
in)='DSN=ODBC_Giovine;UID=postgres;PWD=xxxxxx;DATABASE=giovine;'
conn=50202748, DSN
info(DSN='ODBC_Giovine',server='www.bw4.com',dbase='giovine',user='postgres'
,passwd='xxxxxx',port='5432',readonly='0',protocol='',conn_settings='')
conn=50202748,
SQLDriverConnect(out)='DSN=ODBC_Giovine;DATABASE=giovine;SERVER=www.bw4.com;
PORT=5432;UID=postgres;READONLY=0;PWD=xxxxxx;PROTOCOL=;CONNSETTINGS='
conn=50202748, query=' '
conn=50202748, query='set geqo to 'OFF''
conn=50202748, query='BEGIN'
conn=50202748, query='declare C50215884 cursor for select oid from pg_type
where typname='lo''
conn=50202748, query='fetch 100 in C50215884'
    [ fetched 0 rows ]
conn=50202748, query='close C50215884; END'
conn=50202748, query='BEGIN'
conn=50202748, query='declare C50281496 cursor for select relname, usename
from pg_class, pg_user where relkind = 'r'  and relname !~ '^pg_|^dd_' and
relname !~ '^xinv[0-9]+' and int4out(usesysid) = int4out(relowner) order by
relname'
conn=50202748, query='fetch 100 in C50281496'
    [ fetched 4 rows ]
conn=50202748, query='close C50281496; END'
conn=50202748, query='BEGIN'
conn=50202748, query='declare C50215884 cursor for select * from codifa
where descriz like 'ASPRO%'
'
conn=50202748, query='fetch 100 in C50215884'
    [ fetched 7 rows ]
conn=50202748, query='close C50215884; END'

Unfortunately no c:\mylog.log is generated. I checked three times if I
missed something in copying the DLL but the situation is the following:

PSQLODBC.DLL  145.920 .a.. 17-04-98 11:29:06
PSQLODBC.ORG  133.632 .a.. 15-04-98 12:29:50

And the installed DLL contains the following:

01E4B0   6B 65 79 00  43 6F 75 6C  64 6E 27 74  20 61 6C 6C   key·Couldn't
all
01E4C0   6F 63 61 74  65 20 73 74  61 74 65 6D  65 6E 74 20   ocate
statement
01E4D0   66 6F 72 20  53 51 4C 46  6F 72 65 69  67 6E 4B 65   for
SQLForeignKe
01E4E0   79 73 20 72  65 73 75 6C  74 2E 00 00  2A 2A 2A 2A   ys
result.··****
01E4F0   20 53 51 4C  46 6F 72 65  69 67 6E 4B  65 79 73 28
SQLForeignKeys(
01E500   29 3A 20 45  4E 54 45 52  2C 20 73 74  6D 74 3D 25   ): ENTER,
stmt=%
01E510   75 0A 00 00  00 00 00 00  00 00 00 00  63 3A 5C 6D
u···········c:\m
01E520   79 6C 6F 67  2E 6C 6F 67  00 00 00 00  77 00 00 00
ylog.log····w···
01E530   63 3A 5C 70  73 71 6C 6F  64 62 63 2E  6C 6F 67 00
c:\psqlodbc.log·
01E540   21 21 21 20  43 4F 50 59  5F 52 45 53  55 4C 54 5F   !!!
COPY_RESULT_
01E550   54 52 55 4E  43 41 54 45  44 20 21 21  21 0A 00 00   TRUNCATED
!!!···
01E560   53 51 4C 5F  43 5F 42 49  4E 41 52 59  3A 20 6C 65   SQL_C_BINARY:
le
01E570   6E 20 3D 20  25 64 0A 00  53 51 4C 5F  43 5F 42 49   n =
%d··SQL_C_BI
01E580   54 3A 20 76  61 6C 20 3D  20 25 64 2C  20 63 62 20   T: val = %d,
cb
01E590   3D 20 25 64  2C 20 72 67  62 3D 25 64  0A 00 00 00   = %d,
rgb=%d····
01E5A0   20 20 20 20  53 51 4C 5F  43 5F 43 48  41 52 2C 20
SQL_C_CHAR,
01E5B0   64 65 66 61  75 6C 74 3A  20 6C 65 6E  20 3D 20 25   default: len
= %
01E5C0   64 2C 20 63  62 56 61 6C  75 65 4D 61  78 20 3D 20   d, cbValueMax
=
01E5D0   25 64 2C 20  72 67 62 56  61 6C 75 65  20 3D 20 27   %d, rgbValue
= '


I even tried creating an empty c:\mylog.log file to see if it worked only
in append mode, but with no luck.
I don't know if it is relevant, but I'm running Windows 95 OSR 1.


BTW: don't know if you tried and fixed it but the duplicate table name
problem is still here.
BTW2: probably I know an awful solutions for the guys in trouble with
Delphi (if their tables show all "memoized" data fields):
Reinstall the original BDE (3.0), with a * * WHITE * * About box in the
BDECFG and you are OK.


Dario Fumagalli
email dfumagalli@art-media.it

----------
Da: Byron Nikolaidis <byronn@insightdist.com>
A: Dario Fumagalli <dfumagalli@art-media.it>
Oggetto: Re: [INTERFACES] Re: Possible bugs in ODBC driver
Data: venerdì 17 aprile 1998 18.32

Dario,

I tried to reproduce your problem (since I dont have the Borland products,
I
used Access).  I created the same table you did with the 75 columns and
filled
it with lots of data and at least 7 rows matching "ASPRO%", which is what
your
query apparently returned.  I then used the SQL pass thru option of  MS
Access
to run the same query you did.  For me, it worked.  I got back all the data
and
nothing locked up, etc.

I notice in your logfile that the last line is:
conn=50202748, query='close C50215884; END'

There should be at least one more line like:
'conn=50202748, SQLDisconnect'

This could mean that in freeing up memory and resources, etc., there is a
bug
wreaking havoc, which affects you and not me because of your configuration
or
memory, or because of Borland Builder, etc.

I will see if I can spot any memory bugs but what I really need to do is
try the
same software/database engine you are using.

I will put a debug version of this driver on our web site. It will be at
http://www.insightdist.com/psqlodbc/debug/postdll.zip.  Do you think you
could
temporarily replace the driver you are using (\windows\system\psqlodbc.dll)
with
this debug version, run that same query on the codifa table,  and then send
me
the debug log file (C:\mylog.log)?  This may shed some light on possibly
both
the duplicate table problem and the many-column problem.

One question,  did you say that it is only this query with lots of columns
that
has a problem OR any queries you try with Borland products?

Byron