There is a Details table with a bunch of fields like T_REZKA_NV, T_REZKA_CEQ, T_REZKA_PRIM, etc. In order not to produce unnecessary entities, it was decided to make a separate OperDetails table and place several additional operations into it. Alas, customers require that all this disgrace be presented in a single table, available for editing. Accordingly, several options were tested, and results were obtained of varying degrees of despondency.
Select with joins
SELECT details.*, OperDetails.T_NV T_REZKA2_NV FROM Details LEFT JOIN OperDetails ON Details.NREC = OperDetails.CDetailsin theory, this is the simplest option, but ADOQuery gives an error when trying to make changes to the field of the join table (searches for the T_NV field in Details) and often does not find the record that the cursor is on.
Lookup fields without joins. In this case, the event of inserting a new record is lost, the data in the table is not immediately updated, and in general, somehow everything works very crookedly.
Calculated fields. Here it is impossible to change the value of the field through the grid. Nuff said.
I also tried fields like InternalCalc, but in ADO they turned out to be identical to regular data fields. I remember somewhere I saw how you can generate insertion sentences and modifications dynamically from a select, but it turned out to be powerless to find again. Here you can see the code in more detail .
Please explain what can be done in this case, except to spit, and shove everything into Details.