Post by Robert on Dec 20, 2023 11:57:13 GMT -5
This suggestion is an outgrowth of the recent discussion on Tab Bounds.
When a user has multiple edit tabs open, and the same profile is referenced in more than one tab, the possibility exists that a profile change that is saved in one tab could render the state of the profile information in another tab as deprecated.
I have suggested that this is not a good situation, while George believes users have a legitimate reason to continue editing with the tabs having in-memory copies of profile information being inconsistent. We disagree on this matter, but I would like to offer an alternative for users who feel they want to operate this way.
1. During editing in one tab (let's call it the "original" tab), if any primary command is issued that would result in a saved change to the current profile, a scan would first be made of all other open edit tabs. If any other tab was using the same profile, a popup message would appear in the original tab, along these lines:
"The <cmd-name> command may cause another open tab to have inconsistent Profile information, which may cause editing conflicts including data corruption. Do you wish to continue saving this Profile information? Yes/No". Here, <cmd-name> is any primary command that could alter the Profile, such as DCB.
This way, if the user really wants to operate with inconsistent profiles across tabs, nothing will stop them, but at least they will be notified that the situation exists. I know George believes users are just so smart they will already know this and don't need a reminder, but from my own experience, I personally was not that smart, and didn't know it was happening.
When a Profile is LOCKED, any changes made are not saved, and so if the original tab was running with a locked profile, no check of other open tabs is needed.
2. I believe when a RELOAD occurs, it is not reasonable to do so when the Profile might have been changed somewhere (else). For that reason, I believe that when the RELOAD command is issued, and the profile is unlocked, the edit session should reload the Profile values. That way, we are guaranteed that the data and the Profile that describes it are always in sync.
Again, the LOCK state affects this decision. If editing with a locked profile, it suggests that the user wants the ability to modify Profile settings without saving them. So, a RELOAD while a locked profile is in use should not reload the profile, because that would cause any local/temporary profile settings to be discarded.
If this sort of distinction seems to "subtle" to be accepted, the RELOAD command could be enhanced with an optional [ PROFILE ] operand, which would cause a Profile reload before the data reload was done.
3. Because these issues are affected by the LOCK profile setting, it is a problem if one tab has its LOCK state changed. If that were done, it would be difficult to determine what the correct action should be. I believe a change in LOCK state should prompt a popup warning if other tabs are using the same profile.
The purpose of this proposal is not to hinder users, but to make sure they are aware of potential conflicts. Especially with the advent of EFT, a user might not be aware of these potential conflicts, and it is a courtesy to make them aware of them.
R
When a user has multiple edit tabs open, and the same profile is referenced in more than one tab, the possibility exists that a profile change that is saved in one tab could render the state of the profile information in another tab as deprecated.
I have suggested that this is not a good situation, while George believes users have a legitimate reason to continue editing with the tabs having in-memory copies of profile information being inconsistent. We disagree on this matter, but I would like to offer an alternative for users who feel they want to operate this way.
1. During editing in one tab (let's call it the "original" tab), if any primary command is issued that would result in a saved change to the current profile, a scan would first be made of all other open edit tabs. If any other tab was using the same profile, a popup message would appear in the original tab, along these lines:
"The <cmd-name> command may cause another open tab to have inconsistent Profile information, which may cause editing conflicts including data corruption. Do you wish to continue saving this Profile information? Yes/No". Here, <cmd-name> is any primary command that could alter the Profile, such as DCB.
This way, if the user really wants to operate with inconsistent profiles across tabs, nothing will stop them, but at least they will be notified that the situation exists. I know George believes users are just so smart they will already know this and don't need a reminder, but from my own experience, I personally was not that smart, and didn't know it was happening.
When a Profile is LOCKED, any changes made are not saved, and so if the original tab was running with a locked profile, no check of other open tabs is needed.
2. I believe when a RELOAD occurs, it is not reasonable to do so when the Profile might have been changed somewhere (else). For that reason, I believe that when the RELOAD command is issued, and the profile is unlocked, the edit session should reload the Profile values. That way, we are guaranteed that the data and the Profile that describes it are always in sync.
Again, the LOCK state affects this decision. If editing with a locked profile, it suggests that the user wants the ability to modify Profile settings without saving them. So, a RELOAD while a locked profile is in use should not reload the profile, because that would cause any local/temporary profile settings to be discarded.
If this sort of distinction seems to "subtle" to be accepted, the RELOAD command could be enhanced with an optional [ PROFILE ] operand, which would cause a Profile reload before the data reload was done.
3. Because these issues are affected by the LOCK profile setting, it is a problem if one tab has its LOCK state changed. If that were done, it would be difficult to determine what the correct action should be. I believe a change in LOCK state should prompt a popup warning if other tabs are using the same profile.
The purpose of this proposal is not to hinder users, but to make sure they are aware of potential conflicts. Especially with the advent of EFT, a user might not be aware of these potential conflicts, and it is a courtesy to make them aware of them.
R
