Hi,
Can anyone please tell me how to get the value of predefined variables in the DAL.

Hi,

About what predefined variable are you exactly talking about? Can you elaborate?

- George

Hi,
I want the value of prog.name$.

Actually I m calling the dll from the DAL2 script, and i m in need of session code in the dll. So i m passing session code as parameter to the function in dll.

It will also do if i get the session code in dll.

Hi,

you can use import (http://www.baanboard.com/programmers_manual_baanerp_help_functions_variables_interprocess_transfer_import)/export (http://www.baanboard.com/programmers_manual_baanerp_help_functions_variables_interprocess_transfer_export) functions. From within the Dal, export your variable and import it from the DLL.

I hope it helps,

- George

hi,

The DAL does not recognize session codes (prog.name$) and so cannot evaluate them. Its issue with DAL. U cant have session name in DAL.


Anita

Hi,

If the DAL is directly called via the session you can use the immport function in the dal to import some data from the sessions. These data must be defines as external . But if the DAL is called from another DAL then the import should fail.
session ==> DAL import data from session is OK
session ==> DAL' ==> DAL import data from session fails

Regards
Philippe

Hi,
I am in need of the predefined variables prog.name$ & update.status in DAL. It does not all me for either of them. It gives me Error: as not declared

Is there any way I can get this information in DAL.

I have used "fattr.occurnr" predefined variable but it allows me to compile it successfully also in debugger it gives me the correct value.

Can any one please explain me the reason for it.

Hi,

you can use import (http://www.baanboard.com/programmers_manual_baanerp_help_functions_variables_interprocess_transfer_import)/export (http://www.baanboard.com/programmers_manual_baanerp_help_functions_variables_interprocess_transfer_export) functions. From within the Dal, export your variable and import it from the DLL.

I hope it helps,

- George

Hi,

DAL should implement business rules only and should ideally be unaware of the user interface. DAL should not "know" how it was invoked. It should function the same way if it was invoked in a session through "The Standard Program" or any othe program. What you want to do goes against the whole concept of DAL. I would suggest that you study the DAL concept and then do it the right way. I am telling this as a person who has written many DALs and I can only say how glad I was that I could reuse the same DAL-functionality in different situations and programs. I personally think that DAL rocks!

Hi,

prog.name$ is a session data and is not defined for a DLL or a DAL.
If you want to have it:
a) define an external variable in your session script
b) fill this variable in with prog.name$
c) import this variable (In the DAL)


But as Vahdani said this break the logic of a DAL. A DAL should be independent of the session that call it (for re usability)

Regards
Philippe

Hello,

may i know your exact requirement for which requirement your writting this kind of code?

Regards
Dharam

Hi Vahdani,
Thanks a lot for your reply. I have now moved the functionality in UI script and there I find no problem it works fine there.



Hi,

DAL should implement business rules only and should ideally be unaware of the user interface. DAL should not "know" how it was invoked. It should function the same way if it was invoked in a session through "The Standard Program" or any othe program. What you want to do goes against the whole concept of DAL. I would suggest that you study the DAL concept and then do it the right way. I am telling this as a person who has written many DALs and I can only say how glad I was that I could reuse the same DAL-functionality in different situations and programs. I personally think that DAL rocks!

Hi Vahdani

I know its been a long tme since you posted this, but I have to add a comment... Since check.input of a field is not executed if a DAL is active, its safe to say that all check inputs should be done in the dal. However, the DAL does not know whether data is being inserted or modified. So, for example, if I wish to prevent a record from being inserted (to prevent duplicate[not related to primary key]) this cannot be done in check input. This because the same check will be done during modify.set, preventing a user from modifying his own record











Hi,

DAL should implement business rules only and should ideally be unaware of the user interface. DAL should not "know" how it was invoked. It should function the same way if it was invoked in a session through "The Standard Program" or any othe program. What you want to do goes against the whole concept of DAL. I would suggest that you study the DAL concept and then do it the right way. I am telling this as a person who has written many DALs and I can only say how glad I was that I could reuse the same DAL-functionality in different situations and programs. I personally think that DAL rocks!

i too agree with vahdani and the rest of the guys. pcondi describe the process also accurately because one programmer here did exactly that.

in session script:

|************ program section *******
before.program:
sess.name = "bbwmd3504m001"
export("sess.name", sess.name)

in dal2 script:

extern domain tcmcs.str13 sess.name

#include <bic_dal2>

function extern long before.open.object.set()
{
dal.field.depends.on("bbwmd304.rqty",
HOOK_IS_READONLY + HOOK_IS_MANDATORY, "bbwmd304.stpk")

dal.field.depends.on("bbwmd304.notm",
HOOK_IS_APPLICABLE, "bbwmd304.freq")

import("sess.name", sess.name)

return(0)
}