Once a GI gets beyond a few Data Sources the performance of the Generic Inquiry screen becomes very slow and non productive. Having to wait 15 seconds just to go from the parent Field to the Child Fields is the definition of poor performance.
As an implementation consultant, GIs are fundamental to transformation of data to information. The tools should be efficient and the Generic Inquiry screen has become fat with features but slow with performance.
The Generic Inquiry screen for building and maintaing GIs gets incredibly slow once the GI gets beyond simple
Jeffrey Patch
Exporting to xml and making the changes in xml. It would probably take a lot of trial and error before becoming proficient. Tempting, I could probably do this whilst waiting for the GI editor to move to the next field.😁
- Directly updating the xml may be faster for some types of updates, when you add new Result rows, the system assigns new formula ids. This you cannot do via editing the XML.
- Editing the xml directly leaves the consultant up for the consequences of changes made in error.
- As users we should not have to resort to xml editing to overcome inefficiencies in the system.
- Directly updating the xml may be faster for some types of updates, when you add new Result rows, the system assigns new formula ids. This you cannot do via editing the XML.
- Editing the xml directly leaves the consultant up for the consequences of changes made in error.
- As users we should not have to resort to xml editing to overcome inefficiencies in the system.
Hard agree with your 3rd point. I created a huge comprehensive GI in our system which is similar to the native Production Order Maintenance primary list with more functions.
If I ever want to add another rule to a pre-defined condition, it takes literal ages to move the row up to fit within the brackets.
Also, why can we export the conditions to Excel but not reimport them?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.