Dynamics F/SCM Customer Experience (CRM) Dynamics GP Dynamics Business Central (NAV) Dynamics SL Power Platform Fabric Copilot

[Christine Cook]

Hi all

I have put a flow field  for ‘item ledger No.’ on Table17 ‘G/L Entry’ and Page 20 ‘General Ledger Entries’ from Table 5802 ‘Value Entries’ calling it ‘Item Ledger No’  using  Document no as the relationship.  Can anyone see this causing any issues?  I have done this on my test DB and it all seems to work well but just wanted to check before putting it on live.

regards
Christine

——————————
Christine Cook [Designation]
Procurement International Ltd
Wokingham
——————————

[Jason Wilder]

I can’t think of a reason why a flowfield would cause an issue besides slowing things down a little.  There is an index for Document No. on the Item Ledger Entry table so you should be all set.  I would typically make the flowfield hidden by default but again only for performance reasons.

——————————
Jason Wilder
Senior Application Developer
Stonewall Kitchen
York ME
——————————
——————————————-

[Meenakshi Singh]

I agree. Displaying the flowfield right away might slow down the loading of the page. So, if you want to test the performance, I would suggest keeping it hidden and then display it after the page is opened so you can verify that the flowflow field is not causing any delays.

– Meenakshi

——————————
Meenakshi Singh
Manager of Business Applications
Home Market Foods, Inc.
Norwood MA
——————————
——————————————-

[Franz Kalchmair]

flowfields always can lower the perfomance especially in ledger entries, because ledger entries can be a huge amount. so each posting, saving, loading will be slower before adding that field.
best you give it a try with a copy of the live db as your test db. measure the load time of the page before adding the field and after adding. if load time is ok for you, then it’s ok.
other solution would be a normal integer field, which is filled when posting. existing records can be filled using a batch job.

——————————
Franz Kalchmair
Microsoft MVP
Senior Consultant
Vienna, Austria, Europe
——————————
——————————————-

[Marije Brummel]

Frank,

You know I have a lot of respect for you knowledge, but the info you are sharing here is unfortunately wrong.

Flowfields are not getting slower over time, at least not by design.

To guarantee performance on FlowFields NAV has SumIndexFields. When properly setup NAV will maintain a seperate table, in SQL a View with an Index, to make sure the flowfield is always fast.

In the latest versions of NAV FlowFields are calculated using one single SQL Statement. This requires an index strategy which is optimized for Join statements.

Unfortunately these changes, although one of the best platform improvements since sliced bread, cause all SQL knowledge prior to this change obsolete.

In older versions of NAV creating such SumIndexField was mandatory. Microsoft has chanced that to optional, partly on my advise. It means that you first get to try the performance without, and when slow you need to update your index strategy based on your requirement.

In my opinion, indexes should be a seperate object, or extension if you call it that, to a table to require each customer to run on their own indexes without changing table objects.

——————————
Mark Brummel
NAVUG All-Star
MVP Microsoft Dynamics NAV
Brummel Dynamics Services B.V.
Olst
——————————
——————————————-

[Christine Cook]

thank you for your advice everyone, I have tested on my test (which is a copy of the live too) the page loads very quickly.  I am always cautious with flowfields especially around ledger entry tables

——————————
Christine Cook [Designation]
Procurement International Ltd
Wokingham
——————————
——————————————-