Were using a class based implementation of the OERA and run into a problem skipping the creation of a temp-table record after examining database buffers.
According to the ProDataSets documentation creation can be skipped by using the RETURN NO-APPLY statement in the BEFORE-ROW-FILL event.
But compiling the code shown below generates the following error message:
Cannot RETURN a value from a void method. (13454)
/* Start of code */
&SCOPED-DEFINE PACKAGE-NAME common
&SCOPED-DEFINE ENTITY-NAME client
CLASS curaservices.common.daclient INHERITS dataaccessobject:
METHOD PUBLIC OVERRIDE VOID attachDatasource():
DEFINE VARIABLE cFieldMapping AS CHARACTER NO-UNDO EXTENT 1.
ASSIGN cFieldMapping = ...
METHOD PUBLIC VOID beforeRowFillClient(DATASET ds):
/* End of code */
Could someone help me to tackle this problem?
Windows XP SP2
Is it necessary to use NO-APPLY? Would a simple "LEAVE" do the same thing?
Replacing the RETURN NO-APPLY statement with a LEAVE or UNDO, LEAVE statement did not prohibit the temp-table row to be created.
In that case it may be necessary to change your method to a non-void return type. This shouldn't be an issue as the ABL throws away function calls that return values that aren't assigned to something.
For instance, code can do this:
and that'll compile and work fine. I would expect the same is possible for a method call, ie:
Changing return type in CHARACTER or LOGICAL combined with "RETURN NO-APPLY", "LEAVE" or "UNDO, LEAVE" statements did not work.
Then I'm guessing your next stop is to ping PSC TS.
It has been a while since I've played with this, but wasn't it supposed to be a RETURN-ERROR from the event handler to abort it? I will check to make sure...
Wouldn't return-error have other implications if the only requirement was to avoid making this TT record?
Using RETURN ERROR results in a crash and error message 735!
At least you know your TT record wasn't created.
Yes, I was wrong. The documentation is correct that the event handlers use RETURN NO-APPLY to abort the handler. This is what we've used before. Now that was procedural code, will have to check further for OO based coding. Sorry for the confusion. My memory addressing is somewhat flakey lately :-)
Maybe you should change your Avatar from a wizard to that of a standup comedian.
It wouldn't be the first time I've run into situations where the only redeeming value of some code was that it worked.
OK. There is a bug logged for this actually! It is scheduled to be fixed in the OpenEdge 10.2A release. The bug is the problem you mentioned that the RETURN NO-APPLY does not compile in a VOID method.
So if you need this functionality (BEFORE-ROW-FILL), maybe you can create an external event handler (persistent procedure) that handles this (breaks encapsulation I know) *or* move it to the AFTER-ROW-FILL and take the extra processing of creating a TT row and maybe delete it afterwards...
Thanks for the tip. Using an external event handler did the trick!
Anyone who's interested can contact me for some code samples.