Thread: bug in ODBC driver ?
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
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
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
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
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
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
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