Add new feild to existing table

N

nandanak

New Member
In Progress OpenEdge (10.2B), If we add a new feild to an existing table, Do we need to recompile the programs which already are using that table ?
(In progress 9.1D this is required).
 
Then my sincere apologies to the OP for leading him astray.

So in what circumstances to CRC errors occur in 10.2B?
 
As soon as you modify or delete a database object (table, field, index) that existed when the procedure was compiled. Adding a field or an index does not "modify" the table in that respect. But, AFAIK, if you add a field in the middle and re-order them you will need to re-compile.



Heavy Regards, RealHeavyDude.
 
I'm confused.

My understanding:

  • Tables have CRCs, and indexes have CRCs.
  • A change to a table, even adding a field at the end, changes the CRC.
  • Among many other things, the table CRC (and field list, from what I can see) is compiled into the r-code.

I made a program that displays the contents of a table (with one record and one column), and compiled it. I ran it against the DB and it worked (expected). Then I added a second column to the table and assigned it a value in the record, and then compiled the source again into a new .r.

Now I have two object files compiled from the same source, and each contains a different table CRC. When run, the programs give different results: one displays column 1, the other displays columns 1 and 2. Both run without error.

My confusion is that after making the schema change I expected the first .r to complain about the fact that the table CRC has changed. I expected it to compared the CRC in the metaschema to the CRC in the .r and report a mismatch.

Said another way, in which circumstances would one encounter an 1896 error?
 
Seen what? (it may be that I do not understand you...)

Simply adding tables, fields or indexes does not impact existing r-code. Why would it? They r-code can't try to do anything with them as they didn't exist when it was compiled...

Other sorts of schema fiddling can certainly have an impact though.
 
Sorry, I meant that I have seen 1896 errors in 10.2B. However I can't say definitively that the schema changes involved were additive in nature. They may have been more invasive than the trivial change I tested this afternoon.

Also, I'm not suggesting that an additive schema change would impact the code, per se. I thought rather that it would impact whether the ABL runtime is willing to run the code, as it has evidence (in the form of a CRC mismatch) that the schema against which the code will run is not identical to the schema against which it was compiled.

One other thought: in the case of a field addition, would it matter (in terms of requiring compilation) whether the field was an index component? Certainly that would also change the index CRC.

I guess I just don't have a solid understanding of the set of cases that cause 1896 errors. There is a conventional wisdom in my office that "schema changes necessitate recompilation", and now I am finding that at least some of the time that is not true. I'm trying to determine a more precise definition for "at least some of the time".
 
You cannot add a field to an existing index - so adding a field and making it a component of an index implies also adding the index.
 
Just chucking in my two cents into this thread. Since 10.XA/B I've been adding new fields to existing tables & created new indexes online to live production databases as part of a per-release method and I did not have to recompile any of the source code.
 
You must log in or register to reply here.
Back
Top