We created this site to hear your enhancement ideas, suggestions and feedback about AVEVA products and services. All of the feedback you share here is monitored and reviewed by the AVEVA product managers.
To start, select the product of your interest in the left column. Then take a look at the ideas in the list below and VOTE for your favorite ideas submitted by other users. POST your own idea if it hasn’t been suggested yet. Include COMMENTS and share relevant business case details that will help our product team get more information on the suggestion. Please note that your ideas will first be moderated before they are made visible to other users of this portal.
This page is for feedback for specific AVEVA solutions, excluding PI Systems and Data Hub. For links to these other feedback portals, please see the tab RESOURCES below.
In 7.6, the Find was insensitive but the Replace was sensitive. This resulted in fewer rows being modified than what was found in the Find. In other words, it was a hidden defect.
Making Find and Replace consistent was important to ensure that the users changes were predictable between what was found and what was replaced.
However, making Replace case-inconsistent is less precise, therefore less safe.
In the fix, this consistency was applied to all fields, including linked records. Linking to records in a case insensitive way may result in the wrong record being linked, which could be very dangerous when considering all the ways in which records are linked together across all platform and application functionality, and that it is not until the edit is saved into the backend is the link truly active.
Using ADE, it is not possible to create two points with the same name but differ in case. For example: "Pressure" and "pressure" cannot both exist in the database, since the table index is case-insensitive.
Consider points named: "Foo", "Food", "FoOdy" and "foods"
Filter on "Foo*" matches them all.
Searching "foo*" matches only "foods". Searching on "Foo*" matches only "Foo" and "Food".
Search for "[Ff]oo*" and activate Regular Expressions, it will match "Foo", "Food" and "foods", but not "FoOdy". To match them all, if you didn’t know how case was used, the expression would have to be “[Ff][Oo][Oo]*”.
Enabling Regular Expression on the Search filter is not documented, nor is it easy to use.
User must right click to the left of the string, inside the text field. Not on the binoculars, not on the text itself, and not to the right of the text in the text field.
Regular expression enable pop-up will appear to the right, and does not present an obvious click target to active the checkbox.
Once activated, a small pink “x” will appear where the user right-clicked. Right clicking on this pink “x” will pop-up the regular expression pop-up, and the checkbox will appear checked.
Expectation
Customer is requesting Aveva to modify current ADE table editor search feature to allow input without case sensitivity |
|
Idea business value
Revert the behavior of ADE to what is was before it changed. |
|
Idea Type | Improvement |
Idea priority | 5 – Critical to my company |
Work in | OASYS-E-242 ADE find/replace case sensitivity |
Work status | Will not implement |
Customer has withdrawn their request.
Please note that I’m still unsure if I understand why this is actually an issue for GRT, when we have confirmed that their own naming convention requires all upper case….