Is it an absolute requirement that dal.update/dal.insert/dal.delete must be used in order for a DAL property hook to be executed?

Is using DAL an option with the standard script, ottstpstandard, when it causes a transaction on a table ?

-David B. Clark
dbclark79@juno.com

When a DAL exists for a table does it automatically get invoked when a transaction is perfomed on the table (insert, update, delete) regardless of how the transaction was performed (session, GTM, Baan Exchange, etc.) ??
For a session (Maintain/Display) - yes the DAL does get activated automatically. For GTM (ttaad4100), one has to activate it manually. Press spacebar to activate the menu and from the "Application" pulldown choose "Activate DAL". In Baan 5b I was told the initial versions of Exchange did not support DAL. Baan 5c and the newer versions of Exchange have DAL support. Please investigate further on the issue of Exchange.

OR, it is a requirement that the DAL.UPDATE() function be activated in order for the DAL to be invoked?
If you have an update session, the dal will not fire unless you use dal.* functions.

If I create a new session that has no user-defined program script then the database transactions are handled by the standard script based on the main table of the session. The standard script does not perform DAL.UPDATE() and so is it possible for the DAL to be invoked ?
If this is a maintain session, I would expect the DAL to be in effect. I must confess though that I never have had a session which did not have a user-defined script.

Hi,

Is it an absolute requirement that dal.update/dal.insert/dal.delete must be used in order for a DAL property hook to be executed?
First of all:
- dal.insert must be dal.new() .
- dal.delete must be dal.destroy() .

Property hooks will only be executed in case of dal.new() and dal.update() if you’ve specified that in the fourth argument of those functions. Property hooks will not be invoked in case of dal.destroy() no matter the value of the fourth argument. By the way, it would not make sense to check properties before deletion.
With these functions the DAL will be invoked. So, for dal.new() and dal.update() the before.save.object() and after.save.object() hooks will (among other hooks) be executed (if present). For the dal.destroy() the before.destroy.object() and after.destroy.object() hooks will be executed. In these hooks you can handle related functionality.

If you want to check one or more specific properties you can also call them with dal.start.business.method(“ppmmmxxx”, “ppmmmxxx.dddd.check”, return.value, has.changed)
has.changed can have the following values DAL_NEW, DAL_UPDATE or 0.

Is using DAL an option with the standard script, ottstpstandard, when it causes a transaction on a table ?
No. If you specify a main table for a session that has a DAL then the standard program will automatically invoke the DAL. If the main table does not have a DAL then it cannot be invoked and the standard program will handle equally as in BaanIV.

Hope this answers your questions.

Thank you all very much for your reponses - it has been extremely helpful.

To clarify things a bit, it is my understanding that:

1. DAL is activated when the standard script (ottstpstandard) performs a transaction on a table. (I verified this via a test.)

2. DAL is activated when a transaction is performed on a table via the dal.new(), dal.update() and dal.destroy() functions from within a program script or DLL.

3. DAL is NOT activated when a transaction is performed on a table via the db.insert(), db.update() and db.delete() functions from within a program script or DLL.

Assuming that points #1-3 are correct then it is a reasonable assumption to make that creating a new DAL for a table in standard Baan 5.0 that does not already have a DAL (for example tfgld415) does not necessarily mean that the DAL will be executed. Much of the standard coding in Baan still utilizes the db.insert(), db.udpate() and db.delete() functions.

Hi David,

Point #1-3 are valid.
If a DAL has been created for a table in standard Baan 5.0 that does not already have a DAL (for example tfgld415) then at least point #1 remains valid. I agree that there will still be a lot of db.insert(), db.update() etc. calls that will ignore the DAL, but it is a good start.

David,

Creating a DAL (customization) on a standard table might result in an unstable system: Note that the "check.input" sections of a UI script (aka program script) are ignored once a DAL exists for the main table of a session.

Regards,
Jaap

Jaap,

Thanks for your reply and your advise. Please ellaborate on what you mean by "unstable system". I'm not aware of any down-side risks to creating a customized DAL (in the production VRC) of a standard table (in the standard VRC).

It is also my understanding that the "check.input" has been replaced by DAL in BaanERP 5.0+ and so it should never be used. Furthermore, all program scripts have been updated to reflect this change. Is this understanding incorrect?

Thanks,
-David

OK, I thought that you were about to create a DAL as customization.
If the standard has no DAL and uses the check.input sections, then you cannot create simply a DAL: the check.input will be ignored. (Once a DAL exists, the system assumes that all integrity checks are in the DAL and no longer in the UI script).

If the standard has already a DAL, I assume that all the check.inputs have been converted to the corresponding check hooks in the DAL.

Rgrds,
Jaap

David,

In the past property checks were done in the field section check.input. If you create a DAL then the properties will be checked there. For each property you can create a check:


function extern long ppmmmxxx.dddd.check(long has_changed)
{
on case has_changed
case DAL_NEW:
if ppmmmxxx.dddd = tcyesno.no then
dal.set.error.message(“ppmmmtxxxx.c”)
|* Message description.
return(DALHOOKERROR)
endif
break
case DAL_UPDATE:
break
case 0:
break
endcase

return(0)
}


If a main table of a session has a DAL then in the program scripts the field section check.input will be ignored (i.e. the standard program will skip that section, but will check the DAL to check the property). However the check.input will be invoked by the standard program for non-main-table fields (i.e. form fields).

Jaap’s warning for an ‘unstable system’ is valid. If you do create a DAL then you should do it completely (i.e. all checks that are in the program scripts should be moved to the DAL property checks). If you create in the DAL only some object hooks like before.save.object(), after.save.object() and you ignore the property checks then the system might get unstable because the field check.input will be ignored. This goes for all sessions with that particular main table.

I hope this is clear.

I am clear on the point that the property hooks via DAL have replaced the check.input field-level checks within the program scripts. The property hooks allow the field-level checking consistently regardless of what session is used to interface with a table.

I was under the impression that Baan replaced ALL check.input sections of all program scripts with DAL property hooks. Your responses seem to indicate that this may not be the case and that check.input sections may still exist. Am I understanding your responses correctly?

If this is the case then it may be necessary change the standard program scripts to move the check.input sections of code to the DAL for those standard tables that currently do not have a DAL.
Do you agree with this statement?

What additional feedback can you offer?

Hi,

I was under the impression that Baan replaced ALL check.input sections of all program scripts with DAL property hooks. Your responses seem to indicate that this may not be the case and that check.input sections may still exist. Am I understanding your responses correctly?
Baan introduced the DAL concept in BaanERP 5.0x. So, from Baan IV to BaanERP5.0 there has been a transition from check.input to DAL properties. I don't think for all (main) tables a DAL has been written. If you check the 'tf' package for instance they do not support a lot of DALs. I guess for that package the check.input is still very valuable.

If this is the case then it may be necessary change the standard program scripts to move the check.input sections of code to the DAL for those standard tables that currently do not have a DAL.
Do you agree with this statement?
I think this is a valid statement.