pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedbug in ODBC driver ?
8+ messages / 4 participants
[nested] [flat]
* bug in ODBC driver ?
@ 1998-12-07 05:04 Sergio Kessler <ser@perio.unlp.edu.ar>
1998-12-08 19:42 ` Re: [INTERFACES] bug in ODBC driver ? Byron Nikolaidis <byronn@insightdist.com>
1998-12-14 17:53 ` Re: [INTERFACES] bug in ODBC driver ? Byron Nikolaidis <byronn@insightdist.com>
0 siblings, 2 replies; 8+ messages in thread
From: Sergio Kessler @ 1998-12-07 05:04 UTC (permalink / raw)
To: pgsql-interfaces
Hi (Byron ?),
I think I've found a bug in the postODBC driver, version
6.40.0001.
The problem is with the function SQLGetData.
According to the docs of ODBC, when retrieving long data
(blobs), if the buffer is not enough, this function must
return SQL_SUCCESS_WITH_INFO and SQLSTATE 01004
(String data, right truncated) and in the variable
length_or_ind, it must return the _remaining_ byte
length of the data.
The function is not working this way, ie I call it
(in Delphi):
SQLGetData( hstmt, FieldNo, SQL_BINARY, PChar(TargetValue),
15, @strlen_or_ind);
Note that I put 15 as the buffer size, I _know_ that the
total size of the field (a text field in postgres) is 23
bytes, so this call must return SQL_SUCCESS_WITH_INFO
and SQLSTATE 01004 and the value of strlen_or_ind must
be 8.
But it return SQL_SUCCESS and strlen_or_ind = 23.
Also, the driver, don't must write more bytes than
the buffer size, ie. if the buffer size is 15 the
driver should write no more than 15 bytes.
Maybe this is the cause why other people are insulting the
BDE with blob fields (I don't use the BDE, btw)
Hope this help.
PS: if you will fix this, please, test it with 0 as the
buffer size, because I intend to make two calls, one with
0 (the driver don't write _nothing_ to the buffer) to
know the total bytes of the data and other with this number
as the buffer length.
--
Who is the General Failure and what f* do reading my disk !?
--
Sergio Kessler
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [INTERFACES] bug in ODBC driver ?
1998-12-07 05:04 bug in ODBC driver ? Sergio Kessler <ser@perio.unlp.edu.ar>
@ 1998-12-08 19:42 ` Byron Nikolaidis <byronn@insightdist.com>
1998-12-08 15:14 ` Re: [INTERFACES] bug in ODBC driver ? Sergio Kessler <ser@perio.unlp.edu.ar>
1 sibling, 1 reply; 8+ messages in thread
From: Byron Nikolaidis @ 1998-12-08 19:42 UTC (permalink / raw)
To: Sergio Kessler <ser@perio.unlp.edu.ar>; +Cc: pgsql-interfaces
Sergio Kessler wrote:
> Hi (Byron ?),
>
> I think I've found a bug in the postODBC driver, version
> 6.40.0001.
>
> The problem is with the function SQLGetData.
>
>
I am currently redoing alot of this code. I will definately make sure
the new code works correctly. I can say that the way you describe
SQLGetData functionality is exactly the way it was coded to work,
however, so perhaps it is just a small bug.
Thanks for the bug report.
Byron
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [INTERFACES] bug in ODBC driver ?
1998-12-07 05:04 bug in ODBC driver ? Sergio Kessler <ser@perio.unlp.edu.ar>
1998-12-08 19:42 ` Re: [INTERFACES] bug in ODBC driver ? Byron Nikolaidis <byronn@insightdist.com>
@ 1998-12-08 15:14 ` Sergio Kessler <ser@perio.unlp.edu.ar>
0 siblings, 0 replies; 8+ messages in thread
From: Sergio Kessler @ 1998-12-08 15:14 UTC (permalink / raw)
To: Byron Nikolaidis <byronn@insightdist.com>; +Cc: pgsql-interfaces
Byron Nikolaidis wrote:
>
> Sergio Kessler wrote:
>
> > Hi (Byron ?),
> >
> > I think I've found a bug in the postODBC driver, version
> > 6.40.0001.
> >
> > The problem is with the function SQLGetData.
> >
> >
>
> I am currently redoing alot of this code. I will definately make sure
> the new code works correctly. I can say that the way you describe
> SQLGetData functionality is exactly the way it was coded to work,
> however, so perhaps it is just a small bug.
Any guess about the release date of the new version ?
(my proyect is on hold :)
Cheers,
--
Who is the General Failure and what f* do reading my disk !?
--
Sergio Kessler
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [INTERFACES] bug in ODBC driver ?
1998-12-07 05:04 bug in ODBC driver ? Sergio Kessler <ser@perio.unlp.edu.ar>
@ 1998-12-14 17:53 ` Byron Nikolaidis <byronn@insightdist.com>
1998-12-14 17:24 ` Re: [INTERFACES] bug in ODBC driver ? Sergio <ser@perio.unlp.edu.ar>
1 sibling, 1 reply; 8+ messages in thread
From: Byron Nikolaidis @ 1998-12-14 17:53 UTC (permalink / raw)
To: Sergio Kessler <ser@perio.unlp.edu.ar>; +Cc: pgsql-interfaces
Sergio Kessler wrote:
> Hi (Byron ?),
>
> I think I've found a bug in the postODBC driver, version
> 6.40.0001.
>
> The problem is with the function SQLGetData.
>
> According to the docs of ODBC, when retrieving long data
> (blobs), if the buffer is not enough, this function must
> return SQL_SUCCESS_WITH_INFO and SQLSTATE 01004
> (String data, right truncated) and in the variable
> length_or_ind, it must return the _remaining_ byte
> length of the data.
>
> The function is not working this way, ie I call it
> (in Delphi):
>
> SQLGetData( hstmt, FieldNo, SQL_BINARY, PChar(TargetValue),
> 15, @strlen_or_ind);
>
> Note that I put 15 as the buffer size, I _know_ that the
> total size of the field (a text field in postgres) is 23
> bytes, so this call must return SQL_SUCCESS_WITH_INFO
> and SQLSTATE 01004 and the value of strlen_or_ind must
> be 8.
> But it return SQL_SUCCESS and strlen_or_ind = 23.
>
> Also, the driver, don't must write more bytes than
> the buffer size, ie. if the buffer size is 15 the
> driver should write no more than 15 bytes.
>
> Maybe this is the cause why other people are insulting the
> BDE with blob fields (I don't use the BDE, btw)
>
> Hope this help.
>
Well, I looked into this.
First, the multiple call logic *only* works on LONGVARBINARY fields. In
other words, you can only call SQLGetData multiple times for a field if
its a Large Object type. (At the time, this addition was awesome). It
will not work on BINARY, or VARBINARY. For those, it will simply return
SQL_SUCCESS (it should return SQL_SUCCESS_WITH_INFO and data truncated).
Second, if you do try to use multiple calls on LONGVARBINARY, it works,
but it returns SQL_NO_TOTAL for the amount remaining. Even though this
is not very useful, it is valid according to the odbc spec if the driver
doesn't know how much is left.
So there really is nothing wrong, except the return for binary and
varbinary types. However, time permitting, I will try to enhance the
shortcomings in this area.
Byron
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [INTERFACES] bug in ODBC driver ?
1998-12-07 05:04 bug in ODBC driver ? Sergio Kessler <ser@perio.unlp.edu.ar>
1998-12-14 17:53 ` Re: [INTERFACES] bug in ODBC driver ? Byron Nikolaidis <byronn@insightdist.com>
@ 1998-12-14 17:24 ` Sergio <ser@perio.unlp.edu.ar>
1998-12-14 20:17 ` Re: [INTERFACES] bug in ODBC driver ? Byron Nikolaidis <byronn@insightdist.com>
0 siblings, 1 reply; 8+ messages in thread
From: Sergio @ 1998-12-14 17:24 UTC (permalink / raw)
To: Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
Byron Nikolaidis <byronn@insightdist.com> el día Mon, 14 Dec 1998 12:53:52
-0500, escribió:
>
>
>Sergio Kessler wrote:
>
>> Hi (Byron ?),
>>
>> I think I've found a bug in the postODBC driver, version
>> 6.40.0001.
>>
>> The problem is with the function SQLGetData.
>>
>> According to the docs of ODBC, when retrieving long data
>> (blobs), if the buffer is not enough, this function must
>> return SQL_SUCCESS_WITH_INFO and SQLSTATE 01004
>> (String data, right truncated) and in the variable
>> length_or_ind, it must return the _remaining_ byte
>> length of the data.
>>
>> The function is not working this way, ie I call it
>> (in Delphi):
>>
>> SQLGetData( hstmt, FieldNo, SQL_BINARY, PChar(TargetValue),
>> 15, @strlen_or_ind);
>>
>> Note that I put 15 as the buffer size, I _know_ that the
>> total size of the field (a text field in postgres) is 23
>> bytes, so this call must return SQL_SUCCESS_WITH_INFO
>> and SQLSTATE 01004 and the value of strlen_or_ind must
>> be 8.
>> But it return SQL_SUCCESS and strlen_or_ind = 23.
>>
>> Also, the driver, don't must write more bytes than
>> the buffer size, ie. if the buffer size is 15 the
>> driver should write no more than 15 bytes.
>>
>> Maybe this is the cause why other people are insulting the
>> BDE with blob fields (I don't use the BDE, btw)
>>
>> Hope this help.
>>
>
>Well, I looked into this.
>
>First, the multiple call logic *only* works on LONGVARBINARY fields. In
>other words, you can only call SQLGetData multiple times for a field if
>its a Large Object type. (At the time, this addition was awesome). It
>will not work on BINARY, or VARBINARY. For those, it will simply return
>SQL_SUCCESS (it should return SQL_SUCCESS_WITH_INFO and data truncated).
>
>Second, if you do try to use multiple calls on LONGVARBINARY, it works,
>but it returns SQL_NO_TOTAL for the amount remaining. Even though this
>is not very useful, it is valid according to the odbc spec if the driver
>doesn't know how much is left.
>
>So there really is nothing wrong, except the return for binary and
>varbinary types. However, time permitting, I will try to enhance the
>shortcomings in this area.
According with the Odbc spec (Odbc Sdk 3.5), the multiple call logic
must apply to _all_ length variable fields.
Only in the case of a fixed length field, the driver assume that
the buffer is enough and ignore the TargetValueLength parameter.
I'm using a Text type field, wich is clearly (I hope) variable
length, and as I'm using Borland tools, I unchecked the option
'Text as LongVarChar' in the driver.
I don't know how the driver manage this type of field internally.
Maybe I should check it ? But if it give me SQL_NO_TOTAL is not
very useful to me, as you said.
Regards,
Sergio Kessler
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [INTERFACES] bug in ODBC driver ?
1998-12-07 05:04 bug in ODBC driver ? Sergio Kessler <ser@perio.unlp.edu.ar>
1998-12-14 17:53 ` Re: [INTERFACES] bug in ODBC driver ? Byron Nikolaidis <byronn@insightdist.com>
1998-12-14 17:24 ` Re: [INTERFACES] bug in ODBC driver ? Sergio <ser@perio.unlp.edu.ar>
@ 1998-12-14 20:17 ` Byron Nikolaidis <byronn@insightdist.com>
1998-12-13 13:37 ` Re: [INTERFACES] bug in ODBC driver ? Sergio Kessler <ser@perio.unlp.edu.ar>
0 siblings, 1 reply; 8+ messages in thread
From: Byron Nikolaidis @ 1998-12-14 20:17 UTC (permalink / raw)
To: Sergio <ser@perio.unlp.edu.ar>; +Cc: pgsql-interfaces
Sergio wrote:
> According with the Odbc spec (Odbc Sdk 3.5), the multiple call logic
> must apply to _all_ length variable fields.
>
>
I realize this, but as always, it comes down to a matter of development time.
When your dealing with free software, you have to remember that.
Byron
^ permalink raw reply [nested|flat] 8+ messages in thread
* Re: [INTERFACES] bug in ODBC driver ?
1998-12-07 05:04 bug in ODBC driver ? Sergio Kessler <ser@perio.unlp.edu.ar>
1998-12-14 17:53 ` Re: [INTERFACES] bug in ODBC driver ? Byron Nikolaidis <byronn@insightdist.com>
1998-12-14 17:24 ` Re: [INTERFACES] bug in ODBC driver ? Sergio <ser@perio.unlp.edu.ar>
1998-12-14 20:17 ` Re: [INTERFACES] bug in ODBC driver ? Byron Nikolaidis <byronn@insightdist.com>
@ 1998-12-13 13:37 ` Sergio Kessler <ser@perio.unlp.edu.ar>
0 siblings, 0 replies; 8+ messages in thread
From: Sergio Kessler @ 1998-12-13 13:37 UTC (permalink / raw)
To: Byron Nikolaidis <byronn@insightdist.com>; +Cc: pgsql-interfaces
Byron Nikolaidis wrote:
>
> Sergio wrote:
>
> > According with the Odbc spec (Odbc Sdk 3.5), the multiple call logic
> > must apply to _all_ length variable fields.
> >
> >
>
> I realize this, but as always, it comes down to a matter of development time.
> When your dealing with free software, you have to remember that.
Of course !, please, Byron, don't get me wrong, I just want to
help, I know that you and Insigth are doing wonderful things
for us without receiving any money.
Please, excuse me if my reply go with an unfortunate tone.
--
Who is the General Failure and what f* do reading my disk !?
--
Sergio Kessler
^ permalink raw reply [nested|flat] 8+ messages in thread
* BUG in ODBC driver
@ 1999-10-19 17:15 Sam O'Connor <oconnor@eiffel.com>
0 siblings, 0 replies; 8+ messages in thread
From: Sam O'Connor @ 1999-10-19 17:15 UTC (permalink / raw)
To: pgsql-interfaces
The current ODBC driver has a bug
caused by the loid being cast and
stored in a pointer.
Later on there are two places where
this pointer is dereferenced to
free some memory but there is no
check to see if the current type
is LONG_VAR_BINARY.
I had fixed this in my local copy
of the source but have since had
my laptop's hard disk die. I'll
try to reconstruct the fix in a
few days. (other more important
things to reconstruct in the
meantime) Perhaps someone else
can fix it in the meantime from
the meager description above.
Sam
P.S.
Is anyone else using PG + ODBC from C?
^ permalink raw reply [nested|flat] 8+ messages in thread
end of thread, other threads:[~1999-10-19 17:15 UTC | newest]
Thread overview: 8+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1998-12-07 05:04 bug in ODBC driver ? Sergio Kessler <ser@perio.unlp.edu.ar>
1998-12-08 19:42 ` Byron Nikolaidis <byronn@insightdist.com>
1998-12-08 15:14 ` Sergio Kessler <ser@perio.unlp.edu.ar>
1998-12-14 17:53 ` Byron Nikolaidis <byronn@insightdist.com>
1998-12-14 17:24 ` Sergio <ser@perio.unlp.edu.ar>
1998-12-14 20:17 ` Byron Nikolaidis <byronn@insightdist.com>
1998-12-13 13:37 ` Sergio Kessler <ser@perio.unlp.edu.ar>
1999-10-19 17:15 BUG in ODBC driver Sam O'Connor <oconnor@eiffel.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox