Help needed on identify passed by Reference or not

[Hobby]

hai,

Is there anyway to identify whether a temp-table or dataset is passed as by-reference to the called procedure, from the called procedure...

For example...

run test.p(input dataset d-data by-reference).

/* prodecure test.p) */

input parameter dataset-handle h-data).


i want to know inside test.p is there a way whether it is passed as by refernce or not.

 

[RealHeavyDude]

AFAIK, Nope, not directly.

But, there may be a solution to the underlying issue which creates the need to know this in the first place. If you are willing to share ...

Regards, RealHeavyDude.

 

[Hobby]

Hai
RealHeavyDude,

The reason why i want to know whether it is passed as by-reference or not is to delete that object in the called procedure.
if it is passed by-reference then the statement
delete object h-data will fail.so what i am intenditing to do is an if check before delete object.

 

[RealHeavyDude]

I would either add the NO-ERROR option to the DELETE OBJECT statement and fiddle with the ERROR-STATUS:ERROR and ERROR-STATUS:NUM-MESSAGE attributes

or

use the structured error handling which was introduced with OE 10.1c

to catch the error and act on it accordingly.

Does that make sense to you?

Regards, RealHeavyDude.

 

[MaximMonin]

just add new input parameter procedure (is-by-reference as logical).

 

[Hobby]

Thanks RealHeavyDude for your advice. I will try using the NO-error statement.

I got one more doubt.
This is reguarding the set-call-back procedure "before-row-fill".
Is it possible by anymeans to prevent the fill of current row and go to the next row buy some coding in the before-row-fill procedure.?

 

[KrisM]

Using 'return no-apply.' in your before-row-fill procedure should do the trick.

 

[Hobby]

Thanks KrisM. It worked

 

[TomBascom]

There is a fundamental theorem of dynamic objects -- if you create it, you destroy it. The first corollary to that theorem is that if you didn't create it, you shouldn't be destroying it.

You're violating both the theorem and its corollary. You should expect that your code will be buggy, brittle. unreliable and expensive to create, modify and maintain.