FreeTDS Development Group

["Thompson, Bill D (London)" <bill_d_thompson AT ml.com>]

Hi Mike,

The MS oledb provider is sending 2 sp_cursoroption RPC calls.
the meaning of value 1 in the first parameter to sp_cursoroption to tell
the server to only return the TEXTPTR, 
as opposed to the complete data, for the specified BLOB column (0 for
all columns).

The oledb provider would then get at the BLOB data (if it wanted it) by
other methods, for example a READTEXT language command.

In order to answer your questions about the 0xD1 data, I'd need to see
the full 0xD1 message, accompanied by a description of the column types.

Bill

-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of Mike C.
Sent: 30 September 2004 12:20
To: 'FreeTDS Development Group'
Subject: [freetds] sp_cursoroption and blob fields


Hi all,

I am trying to emulate a server TDS 4.2, and now I'm working on
server-side
cursors.
I can send data to the MS oledb provider by answering to sp_cursorfetch
and
friends, but there's something blurry with blob fields.
When the provider encounters metadata with blobs as response for
sp_cursoropen, it sends a chained sp_cursoroption as following:

0x03 - RPC
RPC name: sp_cursoroption
RPC options: 0
------------
par[0] = 123456 (cursor handle)
par[1] = 1      (option 1)
par[2] = 2      (column number with blob field)
0x80 ---------- (procedure separator ??)
par[3] = "sp_cursoroption"
par[4] = 123456 (cursor handle)
par[5] = 1      (option 1)
par[6] = 4      (column number with blob field)
0x80 ---------- (procedure separator ??)
par[7] = "sp_cursorfetch"
par[8] = 123456 (cursor handle)
par[9] = 0x10   (fetch type - absolute row index)
par[10]= 1      (start row number)
par[11]= 1      (row count to return)
--- eof ---

Tested against a real SQL server, the response to this RPC looks like
-------------------------------------------------------------
0x04 message header - response
----
0x79 return status (0)
0xFE done procedure (status 0x89, info 0xE0, count 0)
---- above repeated for each sp_cursoroption
then
--------
0xD1 ROW token
  field 1
  field 2
  etc.
--------
then
0xFF done inside procedure (status 0x51, info 0xC1, count 1)
0x79 return status (0)
0xFE done procedure (status 0x08, info 0xE0, count 1)
-------------------------------------------------------------

The option "1" from sp_cursoroption seem to truncate the size of each
blob
field passed inside 0xD1 ROW, and the field looks like
------------
10 (probably the TEXTPTR length)
31 03 00 00   00 00 00 00   01 00 00 00  BD 9F 34 00 (probably TEXTPTR)
01 00 00 00 (here should be TIMESTAMP 8 bytes, followed by data, but it
is
only 4 bytes)
------------

Well I tried to send the same thing to the provider, i.e. an arbitrary
16
bytes as TEXTPTR and 01 00 00 00 instead of TIMESTAMP and actual data,
but
the provider seems unphased, and it sends sp_cursorclose right away. If
I
send the whole data, the provider does the same thing, just closes the
cursor. It doesn't report any error in both cases.

Do you guys have any info on the cursor protocol when there are blob
fields
in the metadata?
Or if you can see any magic numbers inside the TEXTPTR area returned by
the
real server.

Thanks,
Mike


_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds 
--------------------------------------------------------
 
If you are not an intended recipient of this e-mail, please notify the 
sender, delete it and do not read, act upon, print, disclose, copy, retain or 
redistribute it. Click here for important additional terms relating to this 
e-mail.     http://www.ml.com/email_terms/ 
--------------------------------------------------------