Crc Error After Online Schema Changes

[jennid]

Hello-We are Progress 10.2B007 (will be upgrading this fall when the newest version of our ERP software is released).

My understanding has been that we should be able to add new fields to existing tables while the database is online. We have done so many times in the past by loading a .df that contains the new fields...only the new fields, no other changes referenced in the .df.

A few months ago, after adding some fields online, CRC errors were being thrown in programs using that table. I found it odd, but it hadn't happened before and it was only on our development system. I chalked it up to something I must have done wrong, recompiled all of the code and moved on.

Today it happened again. So I am digging into it more. I loaded a .df file and selected the option to apply the changes on line. Everything loaded with no errors. Then the CRC errors started happening. I verified that my .df only contained new fields and nothing else. If my memory serves me correctly, I believe the table that this happened with today is the same one I encountered this with in the past. I cannot see anything obviously different about this table compared to others.

Any thoughts on why this happened? We can certainly do all schema changes offline, but our company runs 24x7 and any additional downtime that isn't needed is frowned upon and from everything I've read in the doc, we should be able to do this.

Thanks.

 

[Rob Fitzpatrick]

Just so I am clear, you have confirmed that the .df contained only ADD FIELD statements and no UPDATE FIELD statements?

Also, this article may help:
What dictionary changes force recompiling in OpenEdge?
Knowledge Article

 

[jennid]

Just so I am clear, you have confirmed that the .df contained only ADD FIELD statements and no UPDATE FIELD statements?

Also, this article may help:
What dictionary changes force recompiling in OpenEdge?
Knowledge Article

Correct...only add field. This is exactly what happened:

First, I applied this .df:
ADD FIELD "duetime" OF "pwfrfqqtehdr" AS character
FORMAT "xx:xx"
INITIAL ""
LABEL "Due Time"
POSITION 44
MAX-WIDTH 10
COLUMN-LABEL "Due Time"
ORDER 430



.
PSC
cpstream=ISO8859-1
.
0000007244


The I realized that there was an additional field that was missed...this was about 15 minutes after the first one was applied...I did this one. I can't say for sure if the CRC errors started after the first or second df:
ADD FIELD "duedate" OF "pwfrfqqtehdr" AS date
FORMAT "99/99/99"
INITIAL ?
POSITION 43
MAX-WIDTH 4
ORDER 420

.
PSC
cpstream=ISO8859-1
.
0000007075


I've read the article you mentioned....seeing as we are on 10.2B, shouldn't I be able to do this? Is it some problem that I applied two .df's in fairly short order?

 

[Rob Fitzpatrick]

I'm wondering whether the issue is the order in which the files were applied, i.e. that duetime was added with position 44 and order 430, followed by duedate with position 43 and order 420.

My guess, which I haven't tested, is that if they were applied in the reverse order, or together in a single .df, then you wouldn't see CRC errors. That's what the documentation seems to say.

 

[jennid]

I'm wondering whether the issue is the order in which the files were applied, i.e. that duetime was added with position 44 and order 430, followed by duedate with position 43 and order 420.

My guess, which I haven't tested, is that if they were applied in the reverse order, or together in a single .df, then you wouldn't see CRC errors. That's what the documentation seems to say.

Ahh...you are correct. Thank you...problem solved.