TABLES -It is better to add a new table than to moodify an existing table. If the functionality that you want to add can be done by adding new tables, then that will be easier to upgrade. -It is better to add a new field to an exissting table than to modify the meaning of an existing field. Adding fields to tables is usually not a problem, but there is a limit to the size of a record. You should never change the meaning of a field even if the field is not used by the base system. -It is better to change the name of an existing field than to add a new field if the only purpose is to change the name REPORTS -If you want to make upgrades easier wheen you modify reports, you should always create a copy of an existing report and modify the copy. This is especially true if there are changes to the layout, since they are so hard to document. -When making modifications to code in a codeunit or any other object, try to write your functionality into a separate function. Then you can call that function from within the existing triggers or functions. FORMS write your code so that the server is bothered as little as possible. Also remember that the user has a computer too, so try to spread the processing as much as possible to the client. LOCKTABLE Once a table is locked, none of the other users can use it. Therefore, limit it only to where it is necessary. Remember that an insert, modify, rename or delete will lock the table automatically, so you would not need a Locktable for most modifications. INSERT, MODIFY, DELETE Try to structure your code in such a way that you do not have to look at the return values of these functions. When you use the return value, the server has to be notified right away so that a response can be obtained. If you do not look at them, the server is not notified until something else requires it. Don't worry, if something really bad happens (out of space, and so on), you will still get the run time error which will roll back your changes. CALCSUMS, CALCFIELDS Use these two functions whenever possible rather than spinning through records to add things up. Doing one CALCSUMS or CALCFIELDS takes about the same amount of server time as doing one GET. VALIDITY TESTING Many times, you will be testing user input for validity. Whenever you do so, test things that are available without bothering the server first. That way, if they are invalid, you will not waste the server's time. For example, before doing a GET to test the validity of a user's input, make sure that the user entered something. Temporary Tables Temporary tables allow you to minimize the impact on the server in two main areas: reducing the calls to the server and in allowing you to create records that may not yet exist on the server. Reports often need to read from a particular table; however, the report may need to read from the table many different times depending on the processing being done. Therefore, by reading the data once from the server and storing the data in a temporary table we are able to minimize the impact on the server as well as the amount of network traffic MODIFYALL, DELETEALL Consider setting keys and filters and then using these calls which send only one command to the server, rather than getting and deleting or modifying each of many records, which will send more information back and forth through the network. CALCSUMS, CALCFIELDS Remember that each of these functions allows you to use multiple parameters to sum many fields with one function call (and one network packet). FILTERS Even if a filter is not on a key, it is better to set a filter and have the server skip the records itself, rather than having to get each record and test it yourself before telling the server to get the next record. SUMINDEXFIELDS each SumIndexField takes up a significant amount of space. (They save a lot of time during reports and other data presentation functions, but they take a little extra time during data entry.) Make sure that the amount of time they save will be worth the space that they take up. KEYS Each key takes up a significant amount of space, even without sum fields. Be sure the time they save is worth the space they take. One thing to consider is that if the use for a key (say, a special report) is only significant once a month or once a year, you might deactivate that key and set up a key group so that it can be reactivated without your intervention whenever the user needs it.