Add new feild to existing table

[nandanak]

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).

 

[Cringer]

You will, yes.

 

[nandanak]

@Cringer,

Thanks for your reply .

 

[TomBascom]

Only if you want those programs to know about the new field.

 

[Cringer]

So no CRC errors, Tom??

 

[TomBascom]

That is correct.

 

[Cringer]

Then my sincere apologies to the OP for leading him astray.

So in what circumstances to CRC errors occur in 10.2B?

 

[trmrahim]

@ Tom : that means don't want to compile the programs which are using that table (which we added new field) ?

 

[RealHeavyDude]

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.

 

[Rob Fitzpatrick]

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?

 

[TomBascom]

...in which circumstances would one encounter an 1896 error?

When running an ancient, obsolete and unsupported release of Progress

 

[Rob Fitzpatrick]

No. I can tell you for a fact I've seen this in-house on 10.2B02.

 

[TomBascom]

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.

 

[Rob Fitzpatrick]

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".

 

[TomBascom]

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.

 

[Cecil]

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.