This KB-article explains which schema changes require recompiling and which do not:
http://knowledgebase.progress.com/articles/Article/P167155
That article says:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Which schema changes do NOT REQUIRE recompiling but may affect the code ?
...it is important to remember if you do NOT recompile the code, the change WILL NOT TAKE EFFECT....
...These features will be written to the compiled program at compile time, and will not be updated from the database at runtime....
These application-oriented changes are:
- Adding, changing or removing validation expressions and messages of a table or it's fields.
- Adding, changing or removing schema triggers of a table or it's fields.
- Adding, changing or removing security settings of a table or it's fields.
- Changing the initial value, max value or mandatory requirement of a field in the table.
- Changing the format, label, column-label or help message of of a field in the table.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
I don't know if I have missed something but from that I understood that changing database field's initial value has no effect before you recompile the code that uses this table. However, in my tests this was not the case, the initial value took effect even if I did not recompile (and I made sure I was running r-code and not source code). I tested this with OE10.2B08 and OE11.6.3 on Windows. However, changing field format and label did require recompiling.
Could someone verify if the KB article is misleading/outdated or if I have missed a point. Maybe there are some cases where recompiling really is necessary after changing initial value. What those cases could be?
This was my simple test procedure:
CREATE Test.
VALIDATE Test.
DISPLAY Test.
Table Test had only one character field. After I changed field's initial value, format and label, restarted the session and run the previously compiled test procedure, it created and displayed the record using the new initial value but old format and old label.
The kbase is just a little misleading on that. The initial value does not force a recompilation, so that is correctly stated, but it is retrieved at run time from the database when creating a new record so when you change the value, it is automatically in effect. The kbase is also misleading regarding triggers.
So the statement that says "it is important to remember if you do NOT recompile the code, the change WILL NOT TAKE EFFECT...." should be a little clearer because some of the change will take effect because they are not dependent on the r-code.
Same behavior on 10.1C
The kbase is just a little misleading on that. The initial value does not force a recompilation, so that is correctly stated, but it is retrieved at run time from the database when creating a new record so when you change the value, it is automatically in effect. The kbase is also misleading regarding triggers.
So the statement that says "it is important to remember if you do NOT recompile the code, the change WILL NOT TAKE EFFECT...." should be a little clearer because some of the change will take effect because they are not dependent on the r-code.
Ok, thanks for the information!
Marko,
The initial values for the fields in a table are stored in a “template record”. This template record is kept in the database. When you create a new record, if the template is not already available in the 4GL client, it is fetched from the database. The new record is then created by making a copy of the template record and replacing all the TODAY and NOW fields with the current information.
Changing the initial value(s) of the fields via the dictionary causes the template record to be read, modified, and written back into the database.
Thanks, Gus, for the clarifying info. Based on the KB article you could think that the template record is stored in r-code but it makes sense that it is in the db instead. So, the behavior is fine but the documentation could be a little clearer.