Database and Stored Procedure Customizations

Using the same basic principals that we used to customize the regular Enterprise application, we can customize the database without loosing any of our changes when we update to a new version of the Integral Accounting Enterprise database.

This document will deal with adding new tables, fields, and stored procedures to the database:

First, and most importantly, we recommend NEVER to remove an existing Table, Model, View, Controller, Class, Stored Procedure, or any other system entity to retain forward compatibility. 

 

New Tables & New Fields

When the Integral Accounting Enterprise database is updated, we do not remove any existing fields or tables from the system, nor is the overall table structure or field structure altered. When you run our update scripts to bring your database current, all of the tables, fields, and data within those entities are preserved.

 

Stored Procedures

Adding a new stored procedure to the system

When the Integral Accounting Enterprise update scripts are run, we do not effect any stored procedures that are not part of the existing database, so your new stored procedures will be completely preserved. However, it is still a good idea to give your added  stored procedures a custom prefix that will easily identify that stored procedure as a new one that was added during your customization process.  It is also always a good idea to back-up your custom changes to the stored procedures often.

 

Modifying an Existing Stored Procedure

When modifying stored procedures that are included in the system, you should follow these simple guidelines to make sure that all of your custom changes to the stored procedures are preserved. If you are intend to add a lot of new logic to an existing stored procedure, you should instead add a new custom stored procedure to the system with the new logic, and reference it from the existing stored procedure. Then in the comments of the new stored procedure, you can make a note of the calling point to your new code so it can be easily replaced if lost. If these guidelines are followed, it would be an easy matter to replace the calling line in the new stored procedure to your existing code.

You should also keep a record in the comments of the stored procedure that you have changed or modified that stored procedure, so it can be easily copied into a different location and preserved in case it is accidentally overwritten.