FreeTDS Development Group

[<lists-tds AT mymailfilter.net>]

Thanks for the response James.

The trace I included came directly from an application that accesses an 
MSSQL server via ADO.  It's a sniffer snapshot -- I want to know the 
protocol, so I'm using a packet that's known to work.  In other words, the 
packet I'm trying to "decode" is/was constructed by a Microsoft library.  
I want to better understand how the protocol is being used so I can better 
understand how FreeTDS accomplishes the same thing...

I'm hoping to find some information similar to that already documented 
(http://www.freetds.org/tds.html), such as the "Packet Format" or 
"Response(s)", except for packets with a type of 03.  The more I look at 
it, the more it seems like the data I'm questioning is "parameter" 
related.

Maybe you can tell me how FreeTDS constructs the packet and that'll 
correspond (except perhaps the "sp_execsql") accordingly.  It should be 
enough to understand what's preceding the actual SQL code (I hope).

Thanks again James.


> HTH.  Could I know your name?  

Yes, my name is Jeff Urban.




On Thu, 17 Jul 2003, Lowden, James K wrote:

> > From: lists-tds AT mymailfilter.net [mailto:lists-tds AT mymailfilter.net]
> > Sent: July 17, 2003 1:29 PM
> > 
> > Is the format of the RPC packet known or available somewhere? 
> 
> I was going to say Yes, until I looked at your trace.  That wasn't produced
> by FreeTDS, was it?  Our Type 3 packets include "sp_execsql".  Where did
> this come from?  
> 
> ------------------------||TDS Packet starts w/byte 7 (03)
> 0030  f7 48 ca 56 00 00 03 01 00 fa 00 00 01 00 ff ff   .H.V............
> 0040  0b 00 00 00 00 01 26 04 04 ff ff ff ff 00 00 63   ......&........c
> 0050  00 00 00 00 09 04 00 01 32 ff ff ff ff 00 00 63   ........2......c
> 0060  ba 00 00 00 09 04 00 01 32 ba 00 00 00 64 00 65   ........2....d.e
> 0070  00 63 00 6c 00 61 00 72 00 65 00 20 00 40 00 70   .c.l.a.r.e. .@.p
> 0080  00 34 00 20 00 69 00 6e 00 74 00 65 00 67 00 65   .4. .i.n.t.e.g.e
> 0090  00 72 00 0d 00 0a 00 65 00 78 00 65 00 63 00 20   .r.....e.x.e.c. 
> 00a0  00 6a 00 64 00 5f 00 74 00 65 00 73 00 74 00 5f   .j.d._.t.e.s.t._
> 00b0  00 30 00 30 00 31 00 20 00 40 00 70 00 31 00 3d   .0.0.1. .@.p.1.=
> 00c0  00 33 00 2c 00 20 00 40 00 70 00 32 00 3d 00 27   .3.,. .@.p.2.=.'
> 00d0  00 74 00 65 00 73 00 74 00 27 00 2c 00 20 00 40   .t.e.s.t.'.,. .@
> 00e0  00 70 00 33 00 3d 00 20 00 27 00 30 00 37 00 2f   .p.3.=. .'.0.7./
> 00f0  00 31 00 37 00 2f 00 32 00 30 00 30 00 33 00 27   .1.7./.2.0.0.3.'
> 0100  00 2c 00 20 00 40 00 40 00 70 00 34 00 3d 00 40   .,. .@.@.p.4.=.@
> 0110  00 70 00 34 00 20 00 6f 00 75 00 74 00 70 00 75   .p.4. .o.u.t.p.u
> 0120  00 74 00 0d 00 0a 00 00 00 26 04 04 01 00 00 00   .t.......&......> 
> 
> > Also, there are sometimes characters inserted within the SQL code (in 
> > between parameters and such (N' 2 & etc).  Are the rules 
> > surrounding this known?
> 
> Your example doesn't show any such.  The first explanation that comes to
> mind is that some character data must be explicitly UCS-2, represented as 
> 
>       N'your stuff here'
> 
> > And finally, there is a bit of a "trailer" on the end of each 
> > packet.  
> 
> 0120  00 74 00 0d 00 0a 00 00 00 26 04 04 01 00 00 00 
>       \0  t \0 CR \0 LF \0 \0 ?? ?? ?? ^^ ^^ ^^^^^ ^^
>                                        |  |  |      3 more?
>                                        |  |  + length=0
>                                        |  + final
>                                        + Response packet
> 
> I see a CR/LF pair, a null terminator (or so), two unknown bytes, and a
> server response.  I think.  
> 
> HTH.  Could I know your name?  
> 
> --jkl
> -----------------------------------------
> The information contained in this transmission may contain privileged and 
> confidential information and is intended only for the use of the person(s) 
> named above. If you are not the intended recipient, or an employee or agent 
> responsible for delivering this message to the intended recipient, any 
> review, dissemination, distribution or duplication of this communication is 
> strictly prohibited. If you are not the intended recipient, please contact 
> the sender immediately by reply e-mail and destroy all copies of the 
> original message. Please note that we do not accept account orders and/or 
> instructions by e-mail, and therefore will not be responsible for carrying 
> out such orders and/or instructions.
> 
> 
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds
>