[freetds] Exececute procedure returns errors

David Keith dkeith at logisticshealth.com
Tue Jul 27 14:59:18 EDT 2004


James -

    Thank you very much for taking the time to read through this! It 
must be very tedious. :-)

    I just finished a successful test after spending many hours 
debugging, testing different settings etc. Here's what I found:

    With the threaded datamodule and the standard AstaIO data/metadata 
events, ODBC Express implicitly begins/commits/rolls back/ends 
transactions. With the <child> datamodule, I have to explicitly start 
the transaction, execute the transaction, commit the transaction, end 
the transaction and, in the case of an exception, rollback the 
transaction. My testing so far isn't extensive enough to determine with 
absolute certainty that I have solved the problem. But this does look 
promising.

    I did not use any command-line switches with the logging process. I 
added the export=... directive to /etc/profile, and source'd the file, 
restarted my AstaIO server etc.

    Thanks again.
   
    David Keith

Lowden, James K wrote:

>>From: David Keith
>>Sent: Tuesday, July 27, 2004 12:43 PM
>>
>>10:48:00.226794 processing row tokens.  marker is  ff(DONEINPROC)
>>10:48:00.226837 tds_process_end: more_results = 1
>>                was_cancelled = 0
>>                error = 0
>>                done_count_valid = 1
>>10:48:00.226875                  rows_affected = 2
>>SQLFetch: NO_DATA_FOUND
>>    
>>
>
>Thus endeth a fetch.  
>
>  
>
>>Sending packet @ 10:48:00.227327
>>0000 06 01 00 08 00 00 01 00-                        |........|
>>    
>>
>                ^^ 8-byte language packet
>
>New query sent ... oops!  Where's the rest of the packet?  
>
>  
>
>>10:48:00.227417 tds_process_default_tokens() marker is 
>>79(RETURNSTATUS)
>>10:48:00.227453 tds_process_default_tokens: return status is 0
>>10:48:00.227480 tds_process_default_tokens() marker is fe(DONEPROC)
>>10:48:00.227508 tds_process_end: more_results = 0
>>                was_cancelled = 0
>>                error = 0
>>                done_count_valid = 0
>>10:48:00.227591 tds_process_end() state set to 
>>TDS_IDLE
>>    
>>
>
>More stuff being received.  Different session?  We can't tell.  
>
>  
>
>>Received header @ 10:48:00.227637
>>0000 04 01 00 11 00 36 01 00-                        |.....6..|
>>
>>
>>Received packet @ 10:48:00.227690
>>0000 fd 20 00 fd 00 00 00 00-00                      |. ...... .|
>>
>>
>>10:48:00.227725 tds_process_end: more_results = 0
>>                was_cancelled = 1
>>                error = 0
>>                done_count_valid = 0
>>10:48:00.227761 tds_process_end() state set to
>>TDS_IDLEodbc:SQLColAttributes: fDescType is 1011
>>odbc:SQLColAttributes: fDescType is 1012
>>odbc:SQLColAttributes: fDescType is 1011
>>    
>>
>...
>  
>
>>10:48:05.807666 setting column 3 NULL bit
>>    
>>
>
>We're receiving a (cancelled?) result set, but where were columns 1 and
>2?  
>
>  
>
>>tds_submit_query(): state is PENDING
>>10:48:05.807750 tds_client_msg: #20019: "Attempt to initiate a new SQL
>>Server operation with results pending.".  Connection state is now 1.
>>    
>>
>
>and the ODBC driver finally throws in the towel.  
>
>+++
>
>Things don't look good, David, although we can't be sure because there's
>no session ID in the log.  (That's a known problem.)  The TDS protocol
>doesn't keep one, either, so it's not present in the data.  
>
>Was this log created with "append dump = yes"?  By redirecting stderr?
>Neither?  
>
>If neither, then the log has but one session and there's definitely a
>problem with client threads sharing a single session.  Otherwise, if
>either of the other two methods were used, multiple sessions are
>interleaved in the log.  
>
>Nevertheless, if the log is to be believed, a query was interrupted
>during transmission.  Something else arrived meanwhile.  If those things
>were happening on one session, the application is definitely borked.  If
>not, well, it'll take some intensive debugging and maybe better logging
>to sort it out.  
>
>With repect to the thread/fiber issue, I think we're talking apples and
>oranges.  I'm talking about client threads.  How the server is set up
>doesn't affect the absolute truth about the TDS protocol: results must
>be either read entirely or cancelled before issuing the next query.  
>
>--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.
>If you, as the intended recipient of this message, the purpose of which is to inform and update our clients, prospects and consultants of developments relating to our services and products, would not like to receive further e-mail correspondence from the sender, please "reply" to the sender indicating your wishes.  In the U.S.: 1345 Avenue of the Americas, New York, NY 10105.
>
>
>_______________________________________________
>FreeTDS mailing list
>FreeTDS at lists.ibiblio.org
>http://lists.ibiblio.org/mailman/listinfo/freetds
>  
>





More information about the FreeTDS mailing list