|
I need to write a code for below situation For first day my begining balance will be zero and for next day my begining balance will be ending balance of previous day. Below is the example Intially my BB will be zero for the 1st day and for next day my BB will be ending balance of previous day. Please help me to resolve this Issue. Thanks in advance.
(comments are locked)
|
|
You don't mention the version of SQL Server - I'm expecting 2005 or higher, as this type of thing is much easier with CTEs (available from 2005 onward). This will become even easier when "Denali" gets released into the wild, as that has LAG and LEAD and SUM(ORDER BY) functionality. EDIT - I dropped the static EB column completely (and made sure to reference the previous ending balance as the current starting balance) to "prove" the calculation is working as expected. If you are wanting to run an update on the table you would change the final select to an update statement to update the static EB column if you were wanting to. Initially I stored BB & EB value in table set to 0. I am getting correct EB value but that EB will not transfered to nextday BB value. Please help.
Aug 08 '11 at 07:55 AM
Ronakshah112
Thank you so much.. It is working now.
Aug 08 '11 at 08:31 AM
Ronakshah112
In above table everyday probably 100 rows will be inserted.So there are about 30000 rows. Once I ran this query for certain date it gives me this error. Any idea "The maximum recursion 100 has been exhausted before statement completion."
Aug 09 '11 at 10:11 AM
Ronakshah112
You would get around that limitation using the query hint "MAXRECURSION". Add the following to the end of the command batch: This tells the server to keep going - be careful not to code a tight loop though, otherwise it will never end!!
Aug 10 '11 at 01:25 AM
WilliamD
(comments are locked)
|
|
I'd do it a lot simpler and avoid all that CTE stuff by using Quirky Update. This works faster than CTEs. I feel :)
Aug 09 '11 at 03:12 PM
Ronakshah112
@Ronakshah112 - it is faster because you just run through the table once, whereas my solution joins back onto the table using recursion (will always be slower). Nicely done @Phil Factor (+1), I still haven't played with quirky updates enough. Have you compared it to the new sum(order by) in denali?
Aug 10 '11 at 01:22 AM
WilliamD
I always ring-fence this by using a temp table or table variable to which I can apply a clustered index in order to impose the order I want. You'd have to take this into account if you are using this technique to update a base table. It might affect performance comparisons. Sure, you can do the same thing on a base table if have the correct clustered index, but you have to be very careful to check the results, and retest on every version change.
Aug 10 '11 at 04:24 AM
Phil Factor
Sadly, I have personally experienced the unwanted behaviour of the quirky update, but it was due to my own stupidity which allowed me to disregard the effects of parallellism, which made sense in case when the table has millions of records. It taught me to always include the option (maxdop 1) in the quirky update statements I still love, which are still the best and can be made bulletproof by following simple guidelines outlined by @Jeff Moden in this fascinating 22 pages long article. One thing will always remain true: if you get the quirky update right then the same query will always work correctly in any version of the SQL Server which exists now.
Aug 10 '11 at 07:59 AM
Oleg
(comments are locked)
|

