joy_fernandez
Well Known Member
RE: Back to User Overrides!
After Service Packs and ESUs or ASUs, the users may experience issues with
specific user/application overrides. When a user receives a memory
violation, debug message or JDE just freezes, it may be caused by User
Overrides.
To troubleshoot this as the cause, you would need to work with a System
Administrator and recreate the issue and id the application causing the
problem. You would to have the System Administrator delete all User
Overrides for the application and retest with no user overrides set. Have
the user log out of JDE and back to test.
The other potential issue is the moving Columns around can cause problems
with various business functions. Some business functions anticipate data in
certain area, and when they either don't find it or aren't able to populate
the line of reasoning because of the nature of the user/application
override. Remember that user overrides don't actually move data or modify
tables.
The best defense when working with user overrides is to discourage
individual users from making customizations. As recommended have the BA per
functional area perform the modifications, test, them and then have the
System Administrator push the changes to an entire group or to *PUBLIC, and
then promoted through the environments.
Administering User Overrides:
A user who modifies a format that has been pushed is always a concern.
There is no way of stopping a user from modifying their local machines, what
can be done is to maintain a standard for the users to follow.
If we had written policies discouraging this particular activity, we could
occasionally query the database and find those users who have violated these
standards and delete their modifications. At some point in the game, the
users will give up trying to create new format.
On the other hand, if we don't mind the users creating their own customized
views that could cause other issues - time - and troubleshooting, we can
still push out a standard user override as a base and allow the users to
branch out from there.
After Service Packs and ESUs or ASUs, the users may experience issues with
specific user/application overrides. When a user receives a memory
violation, debug message or JDE just freezes, it may be caused by User
Overrides.
To troubleshoot this as the cause, you would need to work with a System
Administrator and recreate the issue and id the application causing the
problem. You would to have the System Administrator delete all User
Overrides for the application and retest with no user overrides set. Have
the user log out of JDE and back to test.
The other potential issue is the moving Columns around can cause problems
with various business functions. Some business functions anticipate data in
certain area, and when they either don't find it or aren't able to populate
the line of reasoning because of the nature of the user/application
override. Remember that user overrides don't actually move data or modify
tables.
The best defense when working with user overrides is to discourage
individual users from making customizations. As recommended have the BA per
functional area perform the modifications, test, them and then have the
System Administrator push the changes to an entire group or to *PUBLIC, and
then promoted through the environments.
Administering User Overrides:
A user who modifies a format that has been pushed is always a concern.
There is no way of stopping a user from modifying their local machines, what
can be done is to maintain a standard for the users to follow.
If we had written policies discouraging this particular activity, we could
occasionally query the database and find those users who have violated these
standards and delete their modifications. At some point in the game, the
users will give up trying to create new format.
On the other hand, if we don't mind the users creating their own customized
views that could cause other issues - time - and troubleshooting, we can
still push out a standard user override as a base and allow the users to
branch out from there.
