The sections in this guide on dynamic objects taught you that even in a high-level language like ABL, you have to do your own memory management when you use dynamic objects. The basic rule is very simple: You create it, you delete it!

This section re-enforces this basic concept and gives you some examples of things you need to be aware of and techniques to use to make sure that your application does not sprout memory leaks that bring it to a halt when you put it into production.

You should not treat the need for memory management as a reason to avoid programming using dynamic objects. Remember that ABL started out as a strictly static language, where everything was defined in the procedural source code and the compiler resolved every table and field reference. Dynamic objects have been added to the language precisely because they can make your development much more effective, and allow you to reuse procedures and logic, when you need a single operation on different tables, fields, or other objects at different times. You should take full advantage of dynamic objects. You just need to remember to clean up after yourself.

The need for careful programming is especially important because many memory management problems only show up when you run your application over long periods of time in production, and the effects of even small memory leaks cause drastic problems. That is definitely not the time for you to be discovering the problems in your application! A little discipline up front protects you from this.