(Quoting inserted the previous post, for whatever reason!)

So the procedure is: 1) alter the schema using any method you choose, so long as you don't modify or eliminate any of the RAP-required fields (remember you must alter both the "current" table and also the "archive" table in each table pair; then 2) run the RAP database generator, unchecking the option to generate the "archive" table - this rewrites all your access routines, and finally 3) regenerate all your data-layer objects using the database generator, and copy the generated code verbatim into your application's data layer (just like you did the first time when creating the app).

That's all there is to it. In a few seconds RAP regenerates both the routines in your database and the objects in your application data layer, and all the code is error-free.

The long standing issue with schema changes (code generated or otherwise) is what to do with existing table data. With code generation, there really does need to be a hard and fast rule: if Sally Business Analyst wants a Foo column added to the Bar table she has to either identify the default value or accept that the column is Nullable. Sally, most often, hasn't a clue what the answer is, either way. Generation doesn't create the problem, but when coders are in charge, the problem keeps getting fobbed off into byzantine code loops. Generation demands an up front answer. The needy BA's of the world don't like having to be explicit.