Hi!
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!
Josef
I hope, that's not true!
It is!
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:
Mike Fechner
a new field does not impact on existing .r code. Dropping a field would - the .r may reference the old field
Aren't fields part of CRC calculation anymore?
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.
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.
Okay, while you guys are doing all that Visual Designer ABL.NET fancy stuff...
10.1B
- Program P.P that accesses table A, compile into P.R and delete the source P.P
- CRC table A = 123
- Run program P.R --> no CRC error
- Add field A.X
- CRC table A = 456
- Run program P.R --> CRC error
- Delete field A.X
- CRC table A = 123
- Run program P.R --> no CRC error
- Delete field A.Y
- CRC table A = 789
- Run program P.R --> CRC error
10.2A
- Program P.P that accesses table A, compile into P.R and delete the source P.P
- CRC table A = 123
- Run program P.R --> no CRC error
- Add field A.X
- CRC table A = 456
- Run program P.R --> no CRC error
- Delete field A.X
- CRC table A = 123
- Run program P.R --> no CRC error
- Delete field A.Y
- CRC table A = 789
- Run program P.R --> CRC error
Would be interesting to run the same test on 10.1C.
This is based on testing?
Unbelievable. Please, somebody from Progress explain!!!
Honestly. I'd cosider the new behaviour a bug. It's not documented somewhere and it has a big impact on existing and documented behaviour.
10.2 should not get released with this bug.
Ehm...
10.1C
- Program P.P that accesses table A, compile into P.R and delete the source P.P
- CRC table A = 123
- Run program P.R --> no CRC error
- Add field A.X
- CRC table A = 456
- Run program P.R --> no CRC error
- Delete field A.X
- CRC table A = 123
- Run program P.R --> no CRC error
- Delete field A.Y
- CRC table A = 789
- Run program P.R --> CRC error
Admittedly, it takes some getting used to and might require some change in behavior, but why is it a bug? It seems to me that the actual behavior is quite sensible and friendly, whether one understands exactly how it is being done or not. If a program doesn't reference a field, why should it produce an error? That is pretty hard to evaluate when a field is deleted because the program is typically reading records, not fields, but with an addition it is no issue, as long as the database is taking care of any initializations and such.
So it was introduced in 10.1C - that is what I thought.
Now I guess Mike has a problem, as he now probably has this 'bug' in his production systems.
(I for one think it is a great feature and cannot imagine why it would be a problem)
The whole concept of schema integrity is a wholy cow.
I'd like to know the (new) rules. If they are not documented somewhere, I consider it an accidential - while some might believe it's desirable - new behaviour. Which is a synonym for a bug.
Which is a synonym for a bug.
Apparently, it's the other way around. See attachment.
[View:~/cfs-file.ashx/__key/communityserver-discussions-components-files/19/KB_2D00_P125422.txt:550:0]
LOL!!!
Thank you Simon. Now that you found the documentation, I'm satisfied...
All the usual Schema changes will still affect the CRC for a table.
The difference is that in 10.1C or later versions, when a R-code that
has a different CRC for a table is run, a second check is made to see
if the old R-code will still run.
...
Makes sense. Will get used to it!
He may have found documentation in the KB, but was this change ever documented in the documentation or update notes. This is something that I could have used recently.
Has anyone tried adding a field online ?
Oh. 81.
I do agree with you, this is a good improvement. Let remember limitations caused by those previous rules.
By the way this sticks to behaviour that we meet on the other sql engines (no trouble when adding new columns at the end, troubles and recompilation when adding columns in the middle of the table).
As noted in this thread, OpenEdge's CRC validation rules were relaxed in release 10.1C. In that release a release note was created that identified this change in behavior a corresponding change was made to the documentation.
I have included both the release note and the change to the documentation set that highlighted this change.
Note: OE00149133 Type: Behavior Change
CRC check relaxed for r-code
In previous OpenEdge versions, after a field is added to a table, any r-code compiled against the old version of the table will not run, because the CRC in the r-code is different from the CRC in the schema.
For 10.1C, the CRC check is relaxed in some instances. If the change to a table is a simple addition of one or more new fields, the old r-code will still execute, even though the CRCs no longer match. When the CRCs do not match, the AVM tests whether the fields of the table (specifically, their names, data types, extents, and logical field record positions) have changed since the r-code was compiled. If they have not changed, the old r-code should run. One case where it will not run is if one of the new fields has a logical field record position less than one of the old fields (in other words, a new field has been inserted into the logical record position sequence).
In the 10.1C OpenEdge Deployment:Managing ABL Applications, there is a new paragraph in Appendix B:
Database CRC changes that do not prevent r-code execution
Under certain circumstances, database modifications can change the database CRC value but will not require you to recompile existing r-code. You can run r-code without recompiling if:
You add new field to a table with a _Field-rpos value greater than any other field in the table. In other words, the new field cannot be inserted into an existing _Field-rpos sequence.
You make changes to existing fields that do not affect the values of _Field-name, _dtype, _Field-rpos, _Extent.
Note: These exceptions do not apply to dataserver tables. Any changes to dataserver tables require recompiling r-code.
Ok, what have I done wrong ?
10.2A
Added a new logical field to a table (using the data dictionary). Run existing .r code, get a crc error.
Why ?
think I've found it. The new field has a rpos of 36, whilst there are other existing fields with a higher rpos.