R: [INTERFACES] Re: Possible bugs in ODBC driver

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(at)art-media(dot)it

----------
Da: Byron Nikolaidis <byronn(at)insightdist(dot)com>
A: Dario Fumagalli <dfumagalli(at)art-media(dot)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