Hi all,

I am working in Ln version and I executed the session "map integration transacctions" (tfgld4281m000) and "post integrations transacctions" (tfgld4282m000), but the table tfgld483 has no registers when I run these sessions.

Seems that table tfgld483 is filled only when I execute tfgld4583m000 session.

Does anyone know the logic of this table? I am trying to use that for a report.

Thanks.

If someone was interested in this case, Infor has respond this:

“Data access layer (DAL) is a layer of a computer program which provides simplified access to data stored in persistent storage of some kind, such as an entity-relational database. This data access layer is used in turn by other program modules to access and manipulate the data within the data store without having to deal with the complexities inherent in this access. For example, the DAL might return a reference to an object (in terms of object-oriented programming) complete with its attributes instead of a row of fields from a database table. This allows the client (or user) modules to be created with a higher level of abstraction. This kind of model could be implemented by creating a class of data access methods that directly reference a corresponding set of database stored procedures. Another implementation could potentially retrieve or write records to or from a file system
The purpose of this function is to log a integration
transaction addition in finance.
Pre-Conditions:
db.retry.point() should be set in the calling function.
Post-Conditions:
commit.transaction should be executed after this function call.
Input-Fields:
i.guid -> Global Unique Identifier for
the origin of the transaction
Not for user interface purposes.
i.debit.credit.indicator -> Debit/Credit indicator
i.store.fin.company -> The financial company in which
the debit and the credit trans.
will be stored. This has been
defined as the credit fin.comp.
but in futere this might change
as it may not always the best.
i.sortkey.element -> Element Code of the addition
i.sortkey.element.value -> Element value of the addition
Returns:
0 dalhookerror, an dal hook error will be set.

Effects:
Creates records in tfgld483 (Integration transactions Additions)
EndDLLUsage

RETIFNOK(dal.new.object("tfgld483"))
--------------------------------------------------

Add 1 Add read actions to the hooks

The needed related data was already defined in the query-extend. The needed related data must be made current via functions.
These functions must be called within the object- and property-hooks, because it is not possible to provide a general hook.
The basic concept of the solution that must be applied is:

“read the data from referenced tables, containing static data, in the DAL at the moment you need it”,

or

“read the tables containing static data just-in-time”.

This new concept has the advantage that is much more readable and traceable if and when the data needed is read.
Because, the same data is needed at several places, the functions must take care of performance. This can be achieved by using record buffers.
You have to be very careful by using “record buffers for dynamic data”.

In case your header table is “Dynamic (more or less)” during the life cycle of your object, that is: during adding, removing or modifying lines, you have to force the reading of the header whenever you change your record pointer on line level. “

RETIFNOK(...)
especially to be used for calling in your DAL
functions within your DAL, or dll's but not from the UI
early return because of error, has to be handled in GUI.
RETIFNOK.ABORT.TRANS(...)
same as RETIFNOK + abort.transaction() in case of error
|#DAL-2 concept.sn
RETIFNOKF(...)
This define converts DALHOOKERROR into boolean value false

RETIFNOKT(...)
This define converts DALHOOKERROR into boolean value true
|#DAL-2 concept.en