[freetds] sp_cursoroption and blob fields

Thompson, Bill D (London) bill_d_thompson at ml.com
Thu Sep 30 08:30:15 EDT 2004

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.


-----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
I can send data to the MS oledb provider by answering to sp_cursorfetch
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
0xD1 ROW token
  field 1
  field 2
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
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
only 4 bytes)

Well I tried to send the same thing to the provider, i.e. an arbitrary
bytes as TEXTPTR and 01 00 00 00 instead of TIMESTAMP and actual data,
the provider seems unphased, and it sends sp_cursorclose right away. If
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
in the metadata?
Or if you can see any magic numbers inside the TEXTPTR area returned by
real server.


FreeTDS mailing list
FreeTDS at lists.ibiblio.org
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/ 

More information about the FreeTDS mailing list