locked
TDS RPC Request, NTEXTTYPE TYPE_INFO, Optional collation RRS feed

  • Question

  • Hello
    I have an example of a TDS RPC request with an NTEXTTYPE parameter. The parameter's TYPE_INFO bytes don't include COLLATION. Looking at the TYPE_INFO rule(TDS Specification, 2.2.5.6) it says:
    "VARLENTYPE TYPE_VARLEN [COLLATION]" meaning COLLATION is optional but I don't understand how to determine when there should COLLATION and when there shouldn't?
    Thanks on advance
     

    Wednesday, March 17, 2010 4:14 PM

Answers

  • Hi eranvm,

     

    This might be the issue we are encountering – I’m referring to MS-TDS v20100305 (March 5th, 2010).  v20100305 does not have Section 2.1.1.5 (perhaps you just have a typo in your responses)

     

    In v20100305, RPC is defined in Section 2.2.1.5 Remote Procedure Call (under Section 2.2.1 Client Messages), which in turn refers to Section 2.2.6.5  RPC Request.

     

    2.2.6.5 refers to Section 4.6  RPC Client Request (Sample RPC Request Message).

     

    Also,  refer to Section 2.2.5.1.2 Collation Rule Definition:

    The collation rule is used to specify collation information for character data or metadata describing character data.

    This is typically specified as part of the LOGIN7 message or part of a column definition in server results containing character data.

     

    Therefore, if I understand your question correctly, in Section 2.2.6.3 LOGIN7OptionFlags3” and “ClientLCID” apply to your question:

    OptionFlags3

    ·         Represented in least significant bit order.

    ·         fChangePassword: Specifies whether the login request should change.

    o   0 = No change request. ibChangePassword MUST be 0.

    o   1 = Request to change login's password.

    ·         fSendYukonBinaryXML: 1 if XML data type instances are returned as binary XML.

    ·         fUserInstance: 1 if client is requesting separate process to be spawned as user instance.

    ·         fUnknownCollationHandling: This bit is used by the server to determine if a client is able to properly handle collations introduced after TDS 7.2. TDS 7.2 and lower clients are encouraged to use this login packet bit. Servers MUST ignore this bit when it is sent by TDS 7.3 or higher clients. See [MSDN-SQLCollation] and [MS-LCID] document for the complete list of SQL Server Collations and Windows LCIDs.

    ·         0 = The server MUST restrict the collations sent to a specific set of collations. It MAY disconnect or send an error if some other value is outside the specific collation set. The client MUST properly support all collations within the collation set.

    ·         1 = The server MAY send any collation that fits in the storage space. The client MUST be able to both properly support collations and gracefully fail for those it does not support.

     

    ClientLCID

    The language code identifier (LCID) value for the client collation. If ClientLCID is specified, the specified collation is set as the session collation. Note that the total ClientLCID is 4 bytes, which implies that there is no support for SQL Sort orders.

     

    You may also want to take a look at Section 4.2 Login Request for a sample LOGIN7 message.

     

    Please take a look and let me know if this helps answer your question, but at least it gets us on the same page in the TDS Specification.

     

    Regards,

    Mark Miller

    Escalation Engineer

    US-CSS DSC PROTOCOL TEAM

    Friday, April 2, 2010 6:22 PM

All replies

  • Hi Eranvm:
    I have alerted protocol documentation team about your question regarding MS-TDS. A member of the protocol documentation team will respond in this thread soon.
    Regards, Obaid Farooqi
    Wednesday, March 17, 2010 4:32 PM
  • Hi eranvm,

    I will investigate this issue and follow up with you soon.

    Regards,

    Mark Miller

    Escalation Engineer

    US-CSS DSC PROTOCOL TEAM

     

    • Marked as answer by eranvm Monday, March 22, 2010 10:30 AM
    • Unmarked as answer by eranvm Monday, March 22, 2010 10:30 AM
    Friday, March 19, 2010 6:03 PM
  • (my previous post had incorrect forum Sig)

    Hi eranvm,

    I will investigate this issue and follow up with you soon.

    Regards,

    Mark Miller

    Escalation Engineer

    US-CSS DSC PROTOCOL TEAM

    Monday, March 22, 2010 4:57 PM
  • Hi eranvm,

     

    Reference TDS Specification, 2.2.5.6, Type Info Rule Definition: The TYPE_INFO rule applies to several messages used to describe column information.  To clarify your question, are you referring to a Client TDS packet or Server TDS packet?  It seems you are referring to the Server TDS packet.  In which case, the Server TDS will have COLLATION information set for all String types but not Numeric though with an *exception* noted for TDS 7.3: COLLATION only occurs if the type is BIGCHARTYPE, BIGVARCHRTYPE, TEXTTYPE, NTEXTTYPE, NCHARTYPE or NVARCHARTYPE.

     

    I hope that answers your question.

     

    Regards,

    Mark Miller

    Escalation Engineer

    US-CSS DSC PROTOCOL TEAM

    Tuesday, March 23, 2010 7:47 PM
  • Hi

    Actually it's a packet sent from the Client to the Server (section 2.2.1.5). As I said the parameter's header doesn't have the COLLATION bytes. Header looks like that:

    63 9a 00 00 00 9a 00 00 00

    63 means NTEXTTYPE

    9a 00 00 00 is the length (TYPE_VARLEN rule)

    9a 00 00 00 is the length again but as part of the TYPE_VARBYTE rule (which includes TYPE_VARLEN at the beginning)

    In case there was COLLATION there should be 5 bytes between the two length parts.

    So again, I don't know in which cases, in Client to Server RPC packet, there will be COLLATION and in which there won't be.

    Thank you

     

    Wednesday, March 24, 2010 7:21 AM
  • Hi eranvm,

    The section you originally referred to in the TDS specification, 2.2.5.6, implies you are asking about a server TDS packet.  I'd like to ask that you please send me a network trace of the behavior so that I can investigate this and see how this matches up to the specification.

    Please forward the trace to "dochelp @ winse . microsoft . com" (without the spaces).

    Regards,

    Mark Miller

    Escalation Engineer

    US-CSS DSC PROTOCOL TEAM

    Friday, March 26, 2010 7:38 PM
  • Hi

    Unfortunately at the moment I can't provide more information than the packet bytes I already showed in the previous message. Anyway, section 2.2.5.6 is titled "RPC Request" and is referred to by section 2.1.1.5 which is under "Client messages", so I don't understand why you are sure it is a server message. Just to make sure we're not talking about different documents, I work with:

    "[MS-TDS] — v20100125
    Tabular Data Stream Protocol Specification
    Copyright © 2010 Microsoft Corporation.
    Release: Monday, January 25, 2010 "

     

    Thank you

    Eran


    Wednesday, March 31, 2010 3:13 PM
  • Hi eranvm,

     

    This might be the issue we are encountering – I’m referring to MS-TDS v20100305 (March 5th, 2010).  v20100305 does not have Section 2.1.1.5 (perhaps you just have a typo in your responses)

     

    In v20100305, RPC is defined in Section 2.2.1.5 Remote Procedure Call (under Section 2.2.1 Client Messages), which in turn refers to Section 2.2.6.5  RPC Request.

     

    2.2.6.5 refers to Section 4.6  RPC Client Request (Sample RPC Request Message).

     

    Also,  refer to Section 2.2.5.1.2 Collation Rule Definition:

    The collation rule is used to specify collation information for character data or metadata describing character data.

    This is typically specified as part of the LOGIN7 message or part of a column definition in server results containing character data.

     

    Therefore, if I understand your question correctly, in Section 2.2.6.3 LOGIN7OptionFlags3” and “ClientLCID” apply to your question:

    OptionFlags3

    ·         Represented in least significant bit order.

    ·         fChangePassword: Specifies whether the login request should change.

    o   0 = No change request. ibChangePassword MUST be 0.

    o   1 = Request to change login's password.

    ·         fSendYukonBinaryXML: 1 if XML data type instances are returned as binary XML.

    ·         fUserInstance: 1 if client is requesting separate process to be spawned as user instance.

    ·         fUnknownCollationHandling: This bit is used by the server to determine if a client is able to properly handle collations introduced after TDS 7.2. TDS 7.2 and lower clients are encouraged to use this login packet bit. Servers MUST ignore this bit when it is sent by TDS 7.3 or higher clients. See [MSDN-SQLCollation] and [MS-LCID] document for the complete list of SQL Server Collations and Windows LCIDs.

    ·         0 = The server MUST restrict the collations sent to a specific set of collations. It MAY disconnect or send an error if some other value is outside the specific collation set. The client MUST properly support all collations within the collation set.

    ·         1 = The server MAY send any collation that fits in the storage space. The client MUST be able to both properly support collations and gracefully fail for those it does not support.

     

    ClientLCID

    The language code identifier (LCID) value for the client collation. If ClientLCID is specified, the specified collation is set as the session collation. Note that the total ClientLCID is 4 bytes, which implies that there is no support for SQL Sort orders.

     

    You may also want to take a look at Section 4.2 Login Request for a sample LOGIN7 message.

     

    Please take a look and let me know if this helps answer your question, but at least it gets us on the same page in the TDS Specification.

     

    Regards,

    Mark Miller

    Escalation Engineer

    US-CSS DSC PROTOCOL TEAM

    Friday, April 2, 2010 6:22 PM