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

Question

Question

v12 Forms ROW() in a collection makes unusable

asked on April 9 • Show version history

I'll try and keep my tone out of this post, but just a heads up that upgrading to version 12 (on prem) has caused nothing but headaches for me and my team. 

We did an upgrade from 11 to 12 about 2 months ago on this machine. Immediately users could not add more than 6 rows to a collection without the browser showing a pop up 'Wait' window. It's more than just that though, users have to wait over a minute for a new collection row to show. 

This is on classic designer with a ton of jQuery. I decided to 'dissect' the form to see what made it tick. I removed all jQuery and lookups. The problem remained. I removed all field rules, although they added a small amount of speed, the form is still useless. The culprit was this formula in the collection: =ROW(). Meanwhile I have a huge formula that defines a full month name based off a number. 

As soon as I removed the =ROW() formula, it picked up some speed. The only other way to gain speed is to remove field rules and replace them with jQuery. That became exponentially complex. I could get it up 20 rows before it slows down. These users regularly enter 30 to 50 rows into the collection, so this is a workaround. We have the users submit blocks of 20 at a time and they utterly and completely hate that. Also they hate my team now, so that is awesome. Again, this form has been in use for years. Now we have a crisis when users go in to get reimbursed for travel. 

I converted the offending form to modern designer. The problems remains. Surprisingly classic designer is faster by a noticeable margin.

Does any of this sound familiar to anyone? If so how did you handle this? I have another process that has slowed down after upgrading to 12. My VAR tells me their experience has been the exact opposite, so I am confused. 

 

Thanks friends!

1 0

Replies

replied on April 13

Could you open a support ticket? I would recommend grabbing a HAR trace of the network calls in both modern and classic.

I'm assuming you have readonly fields that are populated with this formula. You might be able to resolve this by removing the readonly setting and replacing it with disabled (in modern form field rules), or disabling it via JS or CSS in classic.

1 0
replied on April 13 • Show version history

I'll give that try before submitting a ticket. If I do end up with a ticket, i'll grab a HAR to include. Thanks Zach!

0 0
replied on April 23

FYI from LF Dev team via support ticket:
A bug (ID: 655949) has been filed for the reported issue. We'll keep you updated once this is addressed. 


When this gets resolved, us and many others will pick up some speed :) In the meantime my next move is to convert this form to Modern Designer and use pagination in my collection as recommended by Zach in this thread. 


To be clear, all the field rules and lookups will still fire for the collection rows (not really my issue here anyhow) but the browser will not render all the non-visible fields. I am hoping that will free up some browser resources and make a bit of difference. Fingers crossed. 

Kudos to the LF Support team for a quick turnaround with our ticket. We submitted it Monday and heard back the next day. heart

1 0
replied on April 23

I'll follow that ticket as well, thanks for updating here!

0 0
replied on April 10

I haven't seen the latency that you described...yet! We just published a pretty lengthy Campaign Finance Report form that includes multiple tables. The end user will add, sometimes, hundreds of rows. On submission, these collections are saved in SQL to populate the form so users can add, modify, delete later if amendments are needed. I hope we don't see any issues with this once we push it our to our community! 

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

Sign in to reply to this post.