Well, the bad examples are rising more and more in our tech posts. Too many times, we have the tools or the ideas , but not a good use case. So, this is a real and simple use case:

My customer wants to have the “Search Name” field of the Customer table in the Sales Header table, to make easier searches. This way, users that remember better search names than social reasons of their customer can work better with Sales documents. The “Search Name” must be in the Sales Header table and in the Order List page.

We have two different ways to do that:

• Create a new normal field in Sales Header. Old drag way.
• Create a new flow field Iin Sales Header calculated from Customer. This is the way we have the G/L Account name in G/L Entry table, a flow field calculated from the G/L Account table.

The drag field way

This is the standard way in BC, first step is creating a table extension with this field:

Simple. Next step is not so simple. We have to subscribe in any event to drag and fill this field from Customer to Sales Header:

Can look like simply but you must test correct drag and go forward other possible events. Maybe we need more than this to drag this field from Customer to Sales Header.

Flowfield way

Same of above, first step is create an extension with this field:

But, this is the only step, there is no second step to fill this value. The only remaining task is checking it in the Order List page.

Conclusion. What Will I do?

The smartest way is second one. We don´t need to save an history of this field. We only need it to ease the search and work.

But the old school developers (like me) still are doing most of times first way. Why? Because we have the old C/SIDE mindset of a design without table extensions: the performance was better with a normal field, because get a flowfield value is an implicit inner join with other table.

The problem now is that if you create a field in a table extension the system always must perform an inner join to get the value in both scenarios, normal field and flowfield, because a table extension is another table with the same primary key, and the additional fields.

Theoretically, the effect on system performance may be the same, so the better way is to create a flow field instead of a normal field, in my opinion, and let back the old drag way.