I just found out, that when I add a new column to a table - I do not need to recompile the program. It can be started as is.
That is pretty cool!
I hope, that's not true!
Aren't fields part of CRC calculation anymore?
If so, are we able to run a program after deletion of fields as well? What happens when a deleted field is used in the R-Code? A runtime error?
In that case I get a runtime CRC-Error! (drop a column)
How can adding a field have no effect on the CRC value, but dropping?
Message was edited by:
a new field does not impact on existing .r code. Dropping a field would - the .r may reference the old field
Don't know. Couldn't find anything in the 10.2A docs about this...
I just can't see how they can remove a field without impacting on the CRC.
Adding fields - not a problem.
Adding indicies - should be better than what it is (automatic index rebuild whilst online / etc)
removing indicies - could be a problem if the .r references it. However, automatic index selection if the defined index is missing could be possible
You should also be able to change all aspects of a field (label, format, help, sql-width) online
But, Josef said he did get a CRC error on a dropped column. I.e., it sounds like they have done the sensible thing of avoiding a recompile when nothing in the program is affected, but requiring the recompile when the program would be.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
Yeah, you were actually agreeing with me (that has to be a first!). They can't avoid having to check the CRC when the field is dropped.
Ah - I'd like to add another to the "why can't they" list :
Rename a field - this should be allowed online
Ok. I'm still confused - or even more confused.
One of the achievements in previous releases was, that the same schema receives the same CRC value, to make the deployment of changes in the schema easier.
Now you say (I must admid, I did not test this myself), that adding a field, has no impact no the schema compatibility of prebuilt r-code. This can only be true, if the table CRC value is not affected by the added field.
So table CRC of 4711 + field X = 4711.
Now, when we remove field X, this should have an impact on the CRC.
So table CRC 4711 (which is the result of the previous equasion) - field X <> 4711.
That would is a direct conflict with the previous rule, that the same logical schema has the same CRC value. In other words:
4711 + field X = 4711
now remove field X again
(4711 + field X) - field X <> 4711
because after removing the field again, the CRC needs to be violated.
Result: 4711 <> 4711 which is false.
I'd feel better, if we could get some official statement on this - what exactly has been changed by PSC. And why.
Perhaps they only check the crc if a field has been deleted since the last time the table was updated
But before that change (if there was a change) adding a field and removing the field resulted in the same CRC value.
So let's have a table with the CRC 4711 and add field X. Now let's compile a .p or .cls using field X.
Let's remove X again. The CRC will again be 4711! It has always been that way.
How can the runtime know, that the .p compiled while field X was there has a problem? The only way I can think of, is that the CRC was different while field X was there.
The only possiblity would be if no CRC check is made anymore at all. I can't believe of that for two reasons:
1. Josef reported a CRC error message - so they are still out there
2. If you'd be driving a beta program, wouldn't you tell your participants to test something important like this??? With all it's implications?
Can't it be, that they made a smaller change? Something like, if CRC is not correct and sourcecode is available, try to recompile, before complaining about the CRC?
jmls's head explodes.