nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

DCR pagination

System

Hi All,
I have product dcr which takes **** lot of time to load due to multiple time connections with database through inline cmd to fetch the values and populating the dcr.
Can i convert the single page dcr in multiple page so that loading time actually reduces....?

Thanks
Manu G

Find more posts tagged with

Comments

Migrateduser

I am not using FormPublisher for this

Pawan

Hi Manu,

You can try the Items-per-page attribute in the element < data-type > in your DCT, however, I doubt, it will improve your loading time as inline are supposed to be executed when the form loads not the page.

Migrateduser

Hi Manu,

You can try the Items-per-page attribute in the element < data-type > in your DCT, however, I doubt, it will improve your loading time as inline are supposed to be executed when the form loads not the page.

Thanks Pawan, but if it is still rendering complete dct even with items-per-page attribute in the element then it might not help me...
I don have much info on this attribute where can i get help on this? I have read in Form API pdf about IWDatacapture.getPageCount would this can help me in a way n how?

Pawan

Thanks Pawan, but if it is still rendering complete dct even with items-per-page attribute in the element then it might not help me...
I don have much info on this attribute where can i get help on this? I have read in Form API pdf about IWDatacapture.getPageCount would this can help me in a way n how?

This is inside the formspublisher dev guide and in many threads if you search in this forum. First you need to identify the exact item(s) for which the form is loading slow, then you can have some workaround for that. Is this behaviour consistent in IE and firefox?

ISCBorisB

Thanks Pawan, but if it is still rendering complete dct even with items-per-page attribute in the element then it might not help me...
I don have much info on this attribute where can i get help on this? I have read in Form API pdf about IWDatacapture.getPageCount would this can help me in a way n how?

As has been noted, inline processing takes place upfront to build DC Template. This happens before DCR File is open,
it may not even exist yet (new Form, etc). So, if numerous DB connections really are your performance bottle-necks Paging
will not help you at all. It's way too late.

There are several things you may consider, the most common one is of course caching. Generate and save "ready to go" substitution
Tags from your DBs and make inlines fetch these Cached Files upon DCT rendition. Cache updates must be coordinated with the
the DB update mechanisms and are often implemented as Triggers/Stored Procedures

Migrateduser

Hi,
I have tried using storing values from DB at one go instead of having multi time DB conn. in the xml and reading that xml, but this also didnt much helped.
Do we have control on inline cmd execution depending on visiblity control in the DC Template?

Thanks
Manu G

ISCBorisB

- I have tried using storing values from DB at one go [...] this also didn't much help
If you need help with it - post at least some details.

- Do we have control on inline cmd execution depending on visiblity control in the DC Template?
No. Once again, inline's are used to build a Data Capture Template. Every single one of them
is evaluated upfront.

nipper

- Do we have control on inline cmd execution depending on visiblity control in the DC Template?
No. Once again, inline's are used to build a Data Capture Template. Every single one of them
is evaluated upfront.

Not exactly. I have used written inlines that will load different data depending on the role of a person, or if you have a new DCR or open an existing. Bo's point that this runs at the instanciation of the DCT is accurate, but you can still do some fun things with the inline.

ISCBorisB

Not exactly. I have used written inlines that will load different data depending on the role of a person, or if you have a new DCR or open an existing. Bo's point that this runs at the instanciation of the DCT is accurate, but you can still do some fun things with the inline.

What you do within inline code is certainly up to you, even if you do *nothing*. My only point was that the code will be
unconditionally evaluated for every single "inline" you have

nipper

What you do within inline code is certainly up to you, even if you do *nothing*. My only point was that the code will be unconditionally evaluated for every single "inline" you have

Why yes, I tend to do nothing as often as posible thank you.

I was trying to make the point that inlines offer more flexibility than one normally thinks of. You can do some preprocessing of data in the inline.

Migrateduser

What you do within inline code is certainly up to you, even if you do *nothing*. My only point was that the code will be
unconditionally evaluated for every single "inline" you have

In each inline cmd i give a call to ipl file which actually establish conn to DB and stores the DB results in array which is then printed in the dcr whether it is new form entry or edit existing. Coz of this if there are 50 + inline cmd associated with DCT fields are 50+ DB conn for individual fields.
How this can be reduced so dcr loading time is reduced

Thanks
Manu G

ISCBorisB

In each inline cmd i give a call to ipl file which actually establish conn to DB and stores the DB results in array which is then printed in the dcr whether it is new form entry or edit existing. Coz of this if there are 50 + inline cmd associated with DCT fields are 50+ DB conn for individual fields.
How this can be reduced so dcr loading time is reduced

Thanks
Manu G

There are numerous mechanisms to perform this sort of caching.

For example, you can make your inline code to check some "Ready to go" substitution File. If it's there, use it. If it's
not there and only if it's not there, connect to DB, build the File and return it. This way, at worst you'll connect to
DB once. All subsequent inline calls will have a File (Cache) to use.

Note that you would also have to modify DB processes/procedures so that they delete Cache if relevant Tables change.

Migrateduser

There are numerous mechanisms to perform this sort of caching.

For example, you can make your inline code to check some "Ready to go" substitution File. If it's there, use it. If it's
not there and only if it's not there, connect to DB, build the File and return it. This way, at worst you'll connect to
DB once. All subsequent inline calls will have a File (Cache) to use.

Note that you would also have to modify DB processes/procedures so that they delete Cache if relevant Tables change.

Thanks Boris,
I am not familiar with "Ready to Go" substitution file so cant really comment on whether i have it or not.
I tried caching the DB results and storing in xml and reading the xml through ipl file called via inline cmd and it has improved the loading of dcrs but not that significantly as i wanted.

Thanks
Manu G

ISCBorisB

I tried caching the DB results [...] it has improved the loading of dcrs but not that significantly

Then perhaps you've mis-diagnosed the reason of your performance problem. For example, if you have a Replicant Container
with the single inline-populated item in the DCT, your inline will run only once regardless of the DCR.

Think about it. If "DCR A" has two replicant entries, inline runs once. If "DCR B" of the same Type has two hundred replicant
entries, inline still runs only once. This is so because an "inline" is used to dynamically build DCT, not DCR. You do not have
to do anything to achieve that, it's standard FormsPublisher functionality.

Before performance tuning you'd have to do some profiling. In other words, you have to identify your process bottle-necks first.
Without that you are just guessing and may (will?) spend significant resources to optimize components that have little overall
impact.

Migrateduser

My approach has just reduced the time spent in establishing DB conn and firing select queries for my 50 odd fields in DCT. Though DCT is still runnig 50 inline cmd, now for parsing xml file which is storing the db results.

NE ways I really appreciated your prompt responses.

Thanks
Manu

Adam Stoller

My approach has just reduced the time spent in establishing DB conn and firing select queries for my 50 odd fields in DCT. Though DCT is still runnig 50 inline cmd, now for parsing xml file which is storing the db results.

NE ways I really appreciated your prompt responses.

Thanks
Manu

Do you really need 50 inline commands?
Are the fields that you're putting substitutions in place for that far from one another that you cannot combine them into fewer inline calls?
(each inline is likely firing off a process in which to run the program to perform whatever the operation is that will result in the XML being sent back to the DCT - the fewer inlines, the fewer overhead processes involved)

Without seeing your DCT and your inline script(s) it is rather difficult to propose meaningful ways to improve the performance.

Migrateduser

[QUOTE=ghoti]Do you really need 50 inline commands?
Are the fields that you're putting substitutions in place for that far from one another that you cannot [..] fewer overhead processes involved)
QUOTE]

yes 50 inline cmd are called as each field in the DCT is diff from another and populates different values.
So dont really think performance tuning can be done if the inline exist in DCT. And really not doesnot make sense in putting the single select/multi-select/radio button values of fields in the DCT and then loading the DCR.

Adam Stoller

Do you really need 50 inline commands?
Are the fields that you're putting substitutions in place for that far from one another that you cannot [..] fewer overhead processes involved)
yes 50 inline cmd are called as each field in the DCT is diff from another and populates different values.
So dont really think performance tuning can be done if the inline exist in DCT. And really not doesnot make sense in putting the single select/multi-select/radio button values of fields in the DCT and then loading the DCR.

That's your interpretation of what you are doing - since I don't know the requirements and cannot see the code - I cannot say with any authority that you are wrong - but it still sounds like it to me. An inline can be used to generate an entire DCT - so the fact that you are using 50 inlines to generate 50 fields does not mean that you couldn't use 25 inlines to generate 2 fields each, 5 inlines to generate 10 lines each, or 1 inline to generate all 50 fields.
Again - I don't know the actual code you're writing - so it is difficult to do more than speculate.

Jamik

Do you really need 50 inline commands?
Are the fields that you're putting substitutions in place for that far from one another that you cannot [..] fewer overhead processes involved)
yes 50 inline cmd are called as each field in the DCT is diff from another and populates different values.
So dont really think performance tuning can be done if the inline exist in DCT. And really not doesnot make sense in putting the single select/multi-select/radio button values of fields in the DCT and then loading the DCR.

Our DCTs have multiple fields that contain unique values but we use ONE inline command to build many of the fields out so I think you making 50 inline commands just because each field is unique is way overkill. I suggest you take a look at combining your inline commands down to as few as possible. Just because fields have unique values does not mean they can't be generated from the same inline command. That's part of the power of inline commands is you can create one file that lets you group fields that you want on all your different DCTs. Then if you ever have to make a change to a field(s) you just have to change your inline command file instead of touching every DCT you have. So if you're saying you need 50 inline commands for 50 fields then I say you're doing something incredibly wrong.

Of course, as ghoti says I don't know your requirements or your code so there might be justification but the chances of that are 0.000000001%