Récupérer l'entity à partir de l'enregistrement courant


Dans du code 4D classique, on manipule l’enregistrement courant. Si on veut profiter d’ORDA dans ce type de code, il faudrait manipuler l’entity correspondante. Du coup, 2 questions :
J’ai pas trouvé de moyen immédiat de récupérer l’entity à partir de l’enregistrement courant (comme on peut le faire pour récupérer une entity selection à partir de la sélection courante avec Create entity selection) ?
Est-ce un problème de manipuler en parallèle le même enregistrement sous forme classique et comme entity ?


S’il est certainement possible d’avoir l’enregistrement courant d’un côté et le même en entité d’un autre, je n’en vois pas l’utilité.
Les modifications dans l’un ne seront pas disponibles dans l’autre en tout cas.
Pourquoi vouloir avoir les deux en parallèle ?

Pour insérer du code ORDA à l’intérieur de mon traitement à la mode classique. Par exemple, là j’avais besoin d’une info d’un autre enregistrement de la même table. Immédiat en ORDA, bien pénible sinon.

Ça ne me semble pas être une bonne idée à priori.
Je n’ai pas assez d’infos sur le contexte pour juger de la pertinence de la démarche.
Pour récupérer l’entité facilement, il suffit de faire :

ds.Table.get(Clé primaire de l'enregistrement)

PS : Attention, l’entité sera dans l’état stocké dans la base, pas celui de l’enregistrement courant s’il a été modifié.

I am working with a mature database that’s currently in v17.4. The primary input form relies on the Current Record. But I am pushing ORDA in - so I have a similar situation to you.

My solution is to maintain both, But very carefully. The form expects the current record of a table. The first thing I did was change the form from a Modify Record to a Dialog. All the old code still works. In this particular case there are a number of related tables to deal with. The old code did this using arrays and listboxes. It actually reads all the related records into arrays as it loads. The record has to be specifically set to READ/WRITE to edit it. And to save it deletes all the existing related records and uses ARRAY TO SELECTION to recreate them. I had never seen this scheme before. I get the idea but simply deleting and recreating all those records is just kind of sloppy.

So, to migrate to an ORDA form I have to work in steps. The first step is to begin populating FORM. So in the On load form event I look up the current record in the dataclass and put it in Form as Form.thisRecord. This is easy to do:

Using ORDA I can manipulate this at will. But that isn’t what the user expects. So I have to be careful not to change thisRecord. But I can use it to begin to refactor the way the form deals with the related tables. And that’s what I’m doing listbox by listbox.

I have to stress how careful you need to be using this approach. I would not, for instance, attempt to change values in the Current Record by updating and save Form.thisRecord. With ORDA you can have multiple instances of a reference to the same record.

Yes, using legacy code and orda on same records is similar to what we’re used to with 2 process, 2 users. But the new thing is those 2 are in the same process. Watch the locks.

Hi Kirk,

That’s exactly the point. We will gradually integrate ORDA into our developments but this can only be done gradually and we will have to learn to “juggle” between the two. Indeed, we will have to do this while being very careful but, on the one hand, it will allow us to easily do things that were heavy yesterday (see my example above). And that’s how we will gradually be able to work more and more with ORDA, which is, I imagine, our wish to all.
To come back to my initial question, no other solution than the Get command. Of course, you should limit the use of the entity in reading but it is, as in your case, a very good way to access linked data.

PS : very happy to see that the new forum brings more exchanges between developers of different nationalities

Tout vient à point qui sait attendre
Il suffisait d’agiter moins de drapeaux tricolores :rofl: