You are viewing limited content. For full access, please sign in.

Question

Question

Dependent Dynamic Fields not populating when CacheFieldValues and MaxDropDownLength are set

asked on January 18, 2018

I have a customer that has a total of 5 Dynamic Fields on a single template which is composed of 1 Parent and 4 Dependent Fields.  Their data is such that with any given parent value, there will only ever be 1 returned value per dependent.  So once a parent value is entered, the other 4 fields auto populate.

 

The dataset for the dynamic fields, however, is over 50,000 entries and growing daily, so the parent field responded painfully slow.  We are trying to use the [Settings]CacheFieldValues and [Settings]MaxDropDownLength attributes to resolve the slowdown but that is introducing a new problem.  With the [Settings]CacheFieldValues and [Settings]MaxDropDownLength set, now the dependent fields do not auto populate and clicking or tabbing into them causes a huge delay for each dependent field you enter.  Now the slowdown on the parent field is gone, but has been shifted into each of the dependent fields.

 

Another issue that they are seeing is that the [Settings]CacheFieldValues and [Settings]MaxDropDownLength settings are not implemented in the LF Scanning interface and this is where they must do their indexing.  What is the solution for large dynamic field datasets in the scanning interface?  They say that using a workflow to do the lookup after the parent field is entered is not an option because then they must re-look at the document to verify that the data was keyed in correctly, where if the data is presented through the dynamic field, they can see (in theory) instantly if they miss key the data.

 

On top of the slowness of the Dynamic Fields, they find that if they split the document in the scanning interface, the parent field keeps the value of the original document, but the other fields are blanked out.  If they navigate back to a previously indexed document that is still in the scanning interface (not yet stored to the repository), the dependent fields are all blanked out there as well even though they had been filled in with the initial parent field entry.  This seems to be cosmetic because once the document is stored, the dependent fields are filled in, but they would like the ability to step back an re validate previously indexed documents before storing them.

 

They are using LF Windows Client 10.2.1.953 with LF Scanning 10.2.1.971

2 0

Replies

replied on January 18, 2018

We also have clients that run into this issue.  Slow dynamic fields in the scanning interface and splitting documents missing data.  Would be interested to hear from Laserfiche as well.

1 0
replied on January 19, 2018

Hi,

Just to add to the above, we are also hearing the same feedback described almost exactly as above - where there are big differences in user experiences when using the different 'import' interfaces.

 

0 0
replied on January 19, 2018

For the issue regarding the dependent fields failing to populate and/or being slow, please open a support case so we can investigate further. 

 

The issue about missing dynamic field data upon splitting a document sounds like a bug (#35224) that was fixed in 10.3. 

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.