Dear Friends,
As we go for lot of customizations, and get stuck in performance aspects, ultimately having a huge effect on the usage of the ERP; though of sharing the best practices which a developer should consider while going for customizations. The document have been prepared considering 2012 R2/R3; so while going for developments in 3.0/4.0/2009, please consider only the relevant points from the list.
S.No | Verification Areas |
1. | Avoid client server mix. |
2. | Almost all CRUD operations should run in server. In case of ‘InMemory’ and ‘TempDB’ tables, this needs to be decided based upon where the table is getting created. |
3. | Methods having client interaction should not be executed in server. Method codes should be separated based upon execution tier, if required. |
4. | Display or Edit methods should not have CRUD operations |
5. | Field list should be specified for customized X++ SQL. |
6. | FirstOnly should be used wherever applicable. |
7. | Set based database operations can fall back to row based operation, if necessary skipXX methods are not called. |
8. | Row based operations can be converted to set based operations, wherever applicable. |
9. | Nested SELECTs should be avoided, wherever possible to be converted to JOINs. In case we need fields from a JOIN, use specific field lists; else use EXISTS JOIN or NOTEXISTS JOIN, based upon the requirement. |
10. | FIND should be replaced with SELECTs, taking only those fields which are required; instead of taking the complete tuple (in case we need only a few fields). This also should depend upon the “Table Group” and “Cache Lookup” property combinations of the related tables. |
11. | If code is used to INSERT/UPDATE/DELETE, make sure that validateXXX method is called before the operation. |
12. | INSERT/UPDATE should not happen in Modified or Validate related methods. |
13. | Validations should not happen in Modified related methods. |
14. | If Insert method is overridden and is performed in a loop, suggested to use RecordInsertList. |
15. | Do not write Direct SQL code in forms for retrieval of data. Direct SQL or SPs can be used for reports while fetching huge volume of data. |
16. | Use Post and Pre event functionality for base method modifications (like ValidateField, ValidateWrite, InitValue etc). |
17. | For Queries: Set the fields’ property ‘Dynamic’ to ‘No’ and include only those fields required/used for that table. |
18. | Display methods on grid should be cached. |
19. | SQL queries should be avoided in forms. This slows down the loading of Forms. |
20. | Set appropriate table groups for the tables. |
21. | Set appropriate cache lookups for the tables. |
22. | New tables should be created with non-RecId primary key like surrogate keys, in case there is no primary key. |
23. | Alternate keys are suggested to be created for new tables, in case of the requirement. |
24. | Clustered indices as suggested to be kept for new tables, preferably same as that of the primary key (to retrieve data in a faster way). |
25. | Relations are ideally suggested to be based on PK-FK, wherever applicable. |
26. | New fields are not suggested to be added in standard tables. Extension tables are suggested for the same. |
27. | Please see that TTSBEGIN/TTSCOMMIT used in a clear and well balanced manner. Multiple TTS blocks should be avoided wherever applicable. |
28. | Avoid TTSABORT. |
*This post is locked for comments