Re: stack overflow locking sysprocplan

I will have to check the procedures to see if they have a BEGIN and COMMIT in them, I know we played around with these to see if added them or taking them out would help. I can't remember where we left it as either way did not seem to affect the problem.

You should be worried about the application itself; may be that does a begin work. if it does and nothing is changed (no recompile for your spl) then you will not see evidence that the app is doing the begin work. This is some sort of optimization of the engine; when nothing needs to be changed then begin work does not end up in the trx log; as soon as something changes it puts the begin work in the trx log. What you can do is do a insert into some dummy table in your spl. (recreate it with insert do not forget to run update stats for it.!!) When you select from view using your spl; check if there is a lock on that dummy table. if so then the app is doing begin work; also check when the lock disappears; when it does not then you have an app bug on your hands; go beat up the supplier and tell them to commit trx. you may want to ask the supplier why they are putting begin work in the app. Superboer. BTW afaikr the number of args for an spl is about 390 (could be off here scottish poet correct me if i am wrong....) or check the rel notes. if you have more args then you may be crashing the engine. jda schreef: > I will have to check the procedures to see if they have a BEGIN and > COMMIT in them, I know we played around with these to see if added them > or taking them out would help. I can't remember where we left it as > either way did not seem to affect the problem.