Hi,

the problem, that "prog.name$" doesn't work in DAL's is already discused here. I just found a workaround, from which I hope, that it's: new, proper works and is not already posted ;-)

To read the progname of the current session in a DAL

"get.var(pid,"prog.name$",program.name)" should help.

Where "pid" is a predefined variable, "prog.name$" also and "program.name" is a string varibale, you define as reference, which getvar() fills with the session name.

Hope that helps

My dear Spartacus!

The whole idea of a DAL ist that it should not know a thing about the UI. IMHO if you need to know the UI-name (prog.name$) in your DAL script, then there is definitely something wrong with the programing plan. Maybe if you tell us, what it is that you are trying to do, then we could find out how best to do it.

OK, let's say you have a couple of session's writing to the same table. In the table is a field, in which you fill the name of the session, which actually writes the table. How get the information which session it is?

Btw: I think I unterstand what u mean. You think about things like OO and tiers!?
An other solution could be to fill the fields with the session-information in every GUI-script. But then you have to customize (and know) every session which uses this table. If someone invents a new session, he has also to take care about that. This IMHO a lot more of work and also not that sure.
I think also, the name of an actual session is not a information which only belongs to the GUI-tier.

Kind regards
Richard

Hi,

I think the crucial point is that the behaviour of the DAL is not changed depending on the invoking session. If you want to store the session name in a table field for information purposes only then this is fine. I however would have set the session name in the UI:


field.ppmmm001.xxxx:
when.field.changes:
ppmmm001.sess = prog.name$

Hi,

I understand, what you mean. I wrote that possibility in my former posting. the disadvantage off that is IMHO, that you have to customize more objects, than just the one DAL. That also means maintenance will became much more complicate.
In my special case I just need for some logging (only for information). OK we agree no big deal, but if you search baanboard, you will find more threads in which people, out of what reason ever, need the information about the calling process. And if in one of that cases this information isn't a tablefield your proposal couldn't be used.

What is your suggestion in that case?