I am using the QDA (Quest Development Architecture) in a project that is running for about 10 years now. Instead of doing a ‘big-bang’ conversion I decided to use the QDA for new modules of the project that are being developed. I am using QDA packages for new tables. While we also do maintenance on existing modules, I create the QDA packages while I am coding the new features. This way, in time, all the tables will eventually have the QDA in place and I can still use the ‘old’ code without problems.

This approach shows that you can mix and match using the QDA in existing code. You don’t have to implement the QDA all at once. The first increment of using the QDA involves installing the QDA framework, which can be done by deploying the application. This way the common code will be copied to the directory of your choice. After this step, when you are just using the QDA packages (%_tp, %_qp and %_cp) there is no need to redeploy the common code. If you are using the error framework supplied with the QDA then you should regenerate the error packages every time you deploy new code. Especially when you are using new error codes/messages.

You can even use the QDA packages in new programs in existing packages. Without changing the implementation of existing programs. Using the QDA does not interfere with any existing code (or at least, it shouldn’t). You can even use the new package when building changes to existing programs.

This is just one of the many things you can do with the Quest CodeGen Utility.