FreeTDS Development Group

["Thompson, Bill D (London)" <bill.d.thompson AT baml.com>]

Hey James,

> Looks like your complicated proc is selecting a nullable FLOAT
somewhere.  

I'm pretty sure not...I have an accompanying SQL Profiler trace which
I've been through with a fine tooth comb.

> Could the server possibly be configured to report ignored duplicates
as a kind of implied OUTPUT clause?  

I think something this is more likely....a number of posts seem to point
to something funny going on - for example:

http://us.generation-nt.com/stored-procedure-quits-duplicate-key-was-ign
ored-help-97232512.html

and 

http://www.sqlmonster.com/Uwe/Forum.aspx/sql-server-programming/29962/wi
th-IGNORE-DUP-KEY-how-bypass-server-msg-3604

and

http://social.msdn.microsoft.com/forums/en-US/adodotnetentityframework/t
hread/90a20b43-7f01-4e32-8f00-c69dff8c4efc/


no-one seems to have any answer to the problems these guys have
had...but they look similar...

Cheers,

Bill

-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of
jklowden AT schemamania.org
Sent: 05 October 2010 16:20
To: FreeTDS Development Group
Subject: Re: [freetds] An *old* issue I need some help with


On Tue, Oct 05, 2010 at 02:57:01PM +0100, Thompson, Bill D (London)
wrote:
> 
> I'm executing a statement, which is "exec stored_procedure...."
> The stored procedure is quite complex, but *should* have no result
set.
> My subsequent dblibrary calls to handle the results are tailored to
that
> expectation.

Hi Bill, 

> Received packet @ 2010-10-04 12:48:57.438419
> 0000 ab 88 00 14 0e 00 00 00-00 1a 00 44 00 75 00 70 |........
...D.u.p|
> 0010 00 6c 00 69 00 63 00 61-00 74 00 65 00 20 00 6b |.l.i.c.a .t.e.
.k|
> 0020 00 65 00 79 00 20 00 77-00 61 00 73 00 20 00 69 |.e.y. .w .a.s.
.i|
> 0030 00 67 00 6e 00 6f 00 72-00 65 00 64 00 2e 00 12 |.g.n.o.r
.e.d....|
> 0040 45 00 4c 00 4f 00 4e 00-4d 00 53 00 51 00 45 00 |E.L.O.N.
M.S.Q.E.|
> 0050 42 00 52 00 51 00 31 00-5c 00 53 00 51 00 4c 00 |B.R.Q.1.
\.S.Q.L.|
> 0060 31 00 30 00 12 74 00 77-00 5f 00 62 00 61 00 72 |1.0..t.w
._.b.a.r|
> 0070 00 5f 00 66 00 62 00 69-00 6c 00 5f 00 69 00 6e |._.f.b.i
.l._.i.n|
> 0080 00 73 00 65 00 72 00 74-00 19 00 81 01 00 00 00 |.s.e.r.t
........|
> 0090 21 00 6d 08 00 ff 01 00-c1 00 00 00 00 00 ab 66 |!.m.....
.......f|
> 00a0 00 51 c3 00 00 01 00 10-00 50 00 52 00 4f 00 43 |.Q......
.P.R.O.C|
> 00b0 00 45 00 53 00 53 00 20-00 43 00 4f 00 4d 00 50 |.E.S.S.
.C.O.M.P|
> 00c0 00 4c 00 45 00 54 00 45-00 12 45 00 4c 00 4f 00 |.L.E.T.E
..E.L.O.|
> 00d0 4e 00 4d 00 53 00 51 00-45 00 42 00 52 00 51 00 |N.M.S.Q.
E.B.R.Q.|
> 00e0 31 00 5c 00 53 00 51 00-4c 00 31 00 30 00 0b 74 |1.\.S.Q.
L.1.0..t|
> 00f0 00 77 00 5f 00 62 00 61-00 72 00 5f 00 66 00 62 |.w._.b.a
.r._.f.b|
> 0100 00 69 00 6c 00 60 00 79-00 00 00 00 fe 00 00 e0 |.i.l.`.y
........|
> 0110 00 00 00 00 00         -                        |.....|
> 
> The result set describes a one column result set, with no column name.

http://www.freetds.org/tds.html#t129

> 0080                                  81 01 00 00 00 |.s.e.r.t
........|
> 0090 21 00 6d 08 00                                  |!.m.....
.......f|

81 01 00        one column
   00 00        no user type
   21 00        might be NULL (not sure what 0x02 means) 
   6d           type 109, SYBFLTN
   08           8 bytes
   00           no name
   
> followed by a DONEINPROC token (which shouldn't be here as the stored
> proc has SET NOCOUNT ON....)

I'm not sure NOCOUNT suppresses any and all DONEINPROC packets.  

> This badly skews my program. 

Looks like your complicated proc is selecting a nullable FLOAT
somewhere.  

Could the server possibly be configured to report ignored duplicates as
a kind of implied OUTPUT clause?  

Regards,  

--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

----------------------------------------------------------------------
This message w/attachments (message) is intended solely for the use of the 
intended recipient(s) and may contain information that is privileged, 
confidential or proprietary. If you are not an intended recipient, please 
notify the sender, and then please delete and destroy all copies and 
attachments, and be advised that any review or dissemination of, or the 
taking of any action in reliance on, the information contained in or attached 
to this message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a 
solicitation of any investment products or other financial product or 
service, an official confirmation of any transaction, or an official 
statement of Sender. Subject to applicable law, Sender may intercept, 
monitor, review and retain e-communications (EC) traveling through its 
networks/systems and may produce any such EC to regulators, law enforcement, 
in litigation and as required by law. 
The laws of the country of each sender/recipient may impact the handling of 
EC, and EC may be archived, supervised and produced in countries other than 
the country in which you are located. This message cannot be guaranteed to be 
secure or free of errors or viruses. 

References to "Sender" are references to any subsidiary of Bank of America 
Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are 
Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a 
Condition to Any Banking Service or Activity * Are Not Insured by Any Federal 
Government Agency. Attachments that are part of this EC may have additional 
important disclosures and disclaimers, which you should read. This message is 
subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you 
consent to the foregoing.