Question
Rabobank Netherlands
NL
Last activity: 16 Sep 2015 5:35 EDT
Issue with data table list view in pega 5.5
Hi,
I have a problem with data table in 5.5 .I have created a new data table and added 1587 rows . When i am opening the data table from Application/Data tables i am not able to view some information ,the same when i am opening in excel i am getting all the records.
If i execute Obj-List method against those missing records ,i am getting the result set i.e. these records exists but not visible .Is there any pega defined limit on number of records .Please note,in content table of that DataTableClassEditor instance , Maximum value is set as 500 (which is also read only) .This table is not exposed(mapped to pr_others) .
We have to add this data table in a portal where an admin can modify(add/update/delete) the content of this table.If i am not able to show all the contents , it wouldn't fulfill the requirement properly .
Regards,
Siddhartha
Accepted Solution
Pegasystems Inc.
FR
Personally, I wouldn't use this approach. The main reason is, this won't be flexible enough, easy to change, easy to maintain in other word "build for change".
You are already way above the recommended limit (1000 rows) and as I see it, this limit is already too high. As I said before, you cannot really ask a user to scroll through 1000 records regularly to find the right ones and update them. Even 500 would be a terrible task to do.
As the documentation is saying I would create a dedicated table and maybe add a specific UI with a sort of search screen to return a limited number of rows in order to help the user on his daily job. Especially, because you are not really sure if this number (1587) will increase in the future.
Pegasystems Inc.
FR
Hi,
In PRPC 5.5, Data Tables were used most of the time to handle a small number of rows which were supposed to change quite often. I know the system was having some sort of limitations for performance reasons such as the one you having for Decision Tables (check your help file) :
Performance
Process Commander does not limit the number of rows in a
decision table rule. However, as a best practice to avoid slow performance when
updating the form and also avoid the Java 64KB code maximum, limit your decision
table rules to no more than 300 to 500 rows.
Anyway, are you planning to create a custom portal to modify those instances ? Because if you do, you should be fine then.
Rabobank Netherlands
NL
No like that .We already have a hyperlink named "data table" .Once an user will click ok it we are opening the pega default data table list(Application/Data Tables) .Now from the list user will find appropriate data table , click on open icon at left hand side and the list editor will appear .
Actually we are giving direct access to data tables instances in pega to the users.
Pegasystems Inc.
FR
So your users will have to scroll through 1587 rows in order to modify the right ones ? And how many columns do you have per row ?
That really looks like a lot of records and a terrible task for a user really.
Rabobank Netherlands
NL
It has 10 columns .As you said, i looked into the help file and it says-limit is 1000 with OOTB pr_others .Please find below part from Help file- .I can divide the content and create 2 tables instead of a single one. client is also agreed with that
approach .But is it possible to handle this situation with 1587 rows using OOTB pr_others tables .Yes, you are right, i will be a terrible task for a user, we said the disadvantages,but they want to go with this approach .
It has 10 columns .As you said, i looked into the help file and it says-limit is 1000 with OOTB pr_others .Please find below part from Help file- .I can divide the content and create 2 tables instead of a single one. client is also agreed with that
approach .But is it possible to handle this situation with 1587 rows using OOTB pr_others tables .Yes, you are right, i will be a terrible task for a user, we said the disadvantages,but they want to go with this approach .
Database Table
By default, instances of classes created through this facility are stored in the PegaRULES database table named pr_other and are limited to 1,000 rows.
If your data table may eventually contain hundreds of rows, has high turnover, or may be moved to other Process Commander systems, it is advisable to have the database administrator create a new table for the data table class. The column structure of the new table can be the same as the columns in the pr_other table, or can expose additional scalar properties as desired. After the new table is created, create a database table instance (Data-Admin-DB-Table) that links the Process Commander class with the new table.
Thanks,
Siddhartha
Accepted Solution
Pegasystems Inc.
FR
Personally, I wouldn't use this approach. The main reason is, this won't be flexible enough, easy to change, easy to maintain in other word "build for change".
You are already way above the recommended limit (1000 rows) and as I see it, this limit is already too high. As I said before, you cannot really ask a user to scroll through 1000 records regularly to find the right ones and update them. Even 500 would be a terrible task to do.
As the documentation is saying I would create a dedicated table and maybe add a specific UI with a sort of search screen to return a limited number of rows in order to help the user on his daily job. Especially, because you are not really sure if this number (1587) will increase in the future.