Standard procedure V Internal Procedure giving different results

D

dzmuk

New Member
Hi, I have a procedure which has been written and tested, and all appears to be fine, however I want to use this as an internal procedure, but as soon as it is called as an internal procedure I'm getting different results.

I've even broken it down and tested the following scenario. Create the procedure in the procedure editor and run the procedure, note results. Then added the following:

Run pr-voids. -- At the top of the file after the definitions

Then enclosed the rest of the procedure in:
PROCEDURE pr-voids.

END PROCEDURE.

Then run it again, again the same static database, yet have ended up with different results. Does an internal procedure act/execute any differently? I've used similar methods before and never had this problem.

Any help would be greatly appreciated.
 
The simple answer is no, in general there is little/no difference in running a procedure internally or externally. The extended answer is it might, depending... e.g. could be a var is defined at the top and inside the IP, which could give different results.

Code: 
def var x as char init '1' no-undo.
run abc.
display x.
procedure abc.
def var x as char init '2' no-undo.
display x.
end procedure.

However, you've given us little to go on, as you've not even described what the "different results" are, nor is there any relevant code to look at.

We need more info to answer this... otherwise it's sheer speculation and nothing meaningful.
 
As Larry says your description is too vague to say.

Additional speculation on top of the possibility of conflicting variable definitions is improper buffer scoping. If you do not strongly scope buffers to the internal procedure then they are "borrowed' from the larger scope of the containing procedure which often leads to unanticipated side effects. One simple way to avoid that is to "define buffer tablename for tablename." for each table that is referenced in your internal procedure. This creates a named buffer, scoped to the internal procedure, that has the same name as the table and which prevents the default buffer from being accidentally escalated to the containing procedure. It solves a lot of problems with using IPs.
 
One of the clues here would be looking at the COMPILE LIST for the stand-alone procedure. If you have buffers scoped to the whole procedure, then you are set up to leak. Of course, COMPILE LIST on the combined .p will show you the specific issue.
 
For those who ain't familiar with record locking, buffer and transaction scope, I call them the good, the bad and the ugly :awink: ...


What really strikes me - it's no rocket science and, IMHO, it's basic knowledge to successfully develop applications with Progress, but there are so many developers out there totally oblivious to it ...


Regards, RealHeavyDude.
 
And that's due to something I think you posted the other day - companies aren't prepared to give people proper training. They just leave you to figure it out for yourself. I was fortunate enough to have 6 weeks of training from Progress when I started. I still get it wrong, but at least I should know better! ;)
 
Hi,

Thank you all for your responses. As it turn out specifying a buffer scope for the Internal procedure has resolved the isse.
 
You must log in or register to reply here.
Back
Top