[posted and mailed, please reply in news]
jean_bulinckx (jc*@cin.ufpe.br) writes:
The workflow:
1) Users inserts a row at table A
2) Users inserts one or more rows at B
3) Users inserts lots of rows at C
4) Users inserts lots of rows at D
5) Users updates D
6) Users updates B and C
7) Users updates A and prints a report with all content from the four
tables concerning with the row from A
8) Minutes or hours later users checks for that report and updates A
9) Days later users print a big report from all month data
Problem:
At steps 8) and 9) users tell some rows from some tables are vanished!
First, if business rules requires all or none of all these rows to be
inserted, all should be packed into one transaction.
There are plenty of possible reasons, and without knowledge of your
application it is difficult to tell. The two main tracks are: a) someone
deleted the rows. b) the rows were never committed.
a) could be because of a badly coded program. I recall a horror story from
our application. We could find that random rows in one table were deleted,
and we had no idea of why. I eventually decided to track down the issue,
and found a function that stored procedure that for deleted rows from this
table. The problem was that id that was passed was declared as int in VB,
which is only 16 bits, so the function deleted the wrong rows. (And there
was not need to call the procedure, because the correct rows were handled
anyway.)
b) can happen if timeouts are not handled correctly. Timeouts are client-
side events of which SQL Server does not know about. When a client gets a
timeout, it cancels the query. But cancelling a query does not rollback
any outstanding transactions, even if the transaction was started by
the procedure that was cancelled. So after a timeout, you should always
issue a rollback. (Or disconnect and reconnect.) Or simply set the
timeout to 0, so you don't get them.
Since you say "some rows from some tables", I'm inclined to believe
that a) is more likely. But if you can deduced that all missing rows
are from the last part of the operation, improper timeout handling is
not an unlikely culprit.
--
Erland Sommarskog, SQL Server MVP,
es****@sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp