Skip to Content.
Sympa Menu

freetds - Re: [freetds] Exececute procedure returns errors

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: David Keith <dkeith AT logisticshealth.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Cc: Stephan Marais <smarais AT logisticshealth.com>, sgarland AT astatech.com
  • Subject: Re: [freetds] Exececute procedure returns errors
  • Date: Tue, 27 Jul 2004 13:59:18 -0500

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







Archive powered by MHonArc 2.6.24.

Top of Page