We’re still learning in this area, but it generally seems to be OK to deploy new custom fields as long as you are not needing to unpublish and then republish custom objects in the same area. 

That is to say :

• If this is the first time we are adding and publishing custom objects to a specific LU/area then it seems to be OK. 

• However if you already have some objects published you may need to unpublish those in order to publish more… in those cases you will need to wait until after hours otherwise you can get invalid object issues with errors for the users.

HTH,

Nick

Hi Bruce,

When publishing a Custom Object, Database Objects are generated from the configuration meta data and deployed to the database.

The following happens when you publish:

• Database Objects are generated and deployed to the database.
• Privileged system users are granted access to the database objects.
• Dictionary Cache is refreshed.
• A Presentation Object is created for the new objects.
• The Presentation Object is granted to all necessary roles, i.e., all roles that are granted any of the views belonging to the Logical Unit that is extended.

But in case if you want to unpublish, all the deployed database objects except for the table will be removed. Specially unpublish removes the view and package from the server, this means that if other Custom Objects is referencing any of the attributes, they will not work anymore and possibly throw errors. Simply if you try unpublishing and publishing a custom object, which is related to a form on which an end user is used to work, this would probably felt like virtual system down, because it errors could start to throw. On the other hand, end users may have to wait until the process of publish is completed. If we choose to stop unpublishing, we can not guarantee the consequences. 

Therefore at any stage, if you wanted to unpublish and publish the custom object, the recommendation is to carry out during a maintenance window. 

So in your case, if you are going to change a custom object, and as a result of it, if it is required to unpublish and publish, it’s better to take the safe method by doing during a non peak time.

Thank you so much guys for your very helpful responses!

Bruce

Hi Bruce

We ran into issues during business hours when tables/views were locked and ended up with unsycnronized views causing issues for certain processes/prints.

My IFS consultant recommend off hours for changes.

Dominik

Early after our Apps8 SP1+ go live - we locked up production customer orders.  We published a custom field change during the business day and a user hit the customer order header tables at the same time the publish step was in process - everything that touched customer order header failed on a lock.  We had to restart our Oracle DB.  I highly recommend ONLY publishing custom fields off hours unless you know no user could possibly be in that data area.