Please be careful when you are doing this, I assume you already know what you are doing.
But yes off course, you can bypass DAL in your program. The below piece of code will do it all for you, this will prevent all the DAL checks on the main table for the session.
I wouldn’t recommend bypassing DAL at all, its good to have it on. But if you have some customization where you can’t avoid it, you can’t avoid it.
It is always a good practice to maintain labels instead of simply typing the descriptions on the static forms/report layouts. You can understand the importance of the labels when you are working in multilingual environment.
Many a times there is need to retrieve the description maintained for a label code. You can easily achieve this with a predefined function “tt.label.desc()”
void tt.label.desc( string label_code(19), long label_context, ref string desc() mb )
This returns information of the specified label.
label_code : The label code, including the package code.
label_context : The label’s context.
The possible values are:
•1 General Use (for labels on forms and reports)
•2 Session, Table or Report Descriptions
•3 Enumerate descriptions
•4 Index descriptions
•5 Chart descriptions
•6 Menu and menu field descriptions
•7 Chart Application Option descriptions
•8 Business Object descriptions
•9 Subfunction descriptions
•10 Form Command descriptions
•11 Descriptions for External Use
•12 Cascading item on button descriptions
desc : This returns the longest description (in the user’s current language) of the specified label.
In many cases, we require to know the domain of the variable or table field. This can be achieved very easily using
string domainof( variable )
The domainof() function is a compile time function which returns the name of the domain of the supplied variable. Make sure that the variable passed as an argument must be a domain type, otherwise it will result in a compile time error. You can also pass the table fields to the function as an argument.
What makes you forget me ?
These are not my words, its “api.mode” whose trying to remind everyone, that the predefined variable exists and is really of use most of the times in BaaN customisations.
Being a tools consultant worked on multiple sites, Baan flavours and clients across the globe, one thing I have noticed is, “api.mode” is totally been forgotten at 5/10 clients I have visited.
Developers duplicate the entire session just to avoid a popping error message, when a session is running in a job or when AFS is used, despite of the fact that they know about “api.mode”, but missed to use it.
below is just a reminder and usage of “api.mode”
check.input: if not api.mode then // Popup the message else // Log the error message to error log endif
Its that simple, If the value of the variable is 0, that means the application is not running at the background and has the UI.
Another programming feature highly missed out are the application locks, despite of the fact that people know that it exists. Will discuss more about the locks in future posts.