Creating incremental df file from 2 different df files

Question

Is there a method to create an incremental .df file from 2 different .df files? Or do I have to load both files into 2 blank databases and then use the create incremental .df file feature from Data Administration tool?

I'm using Openedge 10.2B08

Answer 1

A Data Definition (.df) file is a listing of things to add, drop or update in a database. It is in plain text so you can view it in a text editor. You can cut-and-paste the contents of one .df file into another. However, you may run into problems if the changes from the two files conflict. For example, file 1 may say to drop field xyz, while file 2 says to update field xyz. This will cause an error and the entire .df will be backed out.

If you're sure there are no conflicts, just paste the contents of file 2 into file 1, just above the footer. The footer is the last five lines in the file:

.
PSC
cpstream=ISO8859-1
.
0000000610

The very last line is a character count. You may have trouble loading the new .df if you don't update that to match the new file length. And be sure to test the .df before trying it in production.

Answer 2

Loading them both in a blank database then dumping one solid DF remains the best solutions in my opinion.

Of course you could shaves a couple of minutes by appending one file to the other, I think you can even remove the footer and not bother, it should work.

As with everything it depends on the critical aspect of the situation. Are you looking at important downtime on a production database? Usually there shouldn't be much compromise on whatever will be applied to production. A solid DF is better than a "hacked 99.9% safe" one. That's the difference between a good and bad Dba. The good one may seems to work a bit slower over a decade. But once in that decade the bad one will eventually provoke some critical downtime to a business...totally offsetting the silly productivity advantage he may looks like to have.

I fixed countless mistakes all around for the past 15 years, I made one. It's not a fun feeling. Being waked up early Monday by a panicked helpdesk guy that describes the issue. Quickly realising it's related to the previous night maintenance I made. Replying to get all users out, country wide going to an halt while I'm trying to figure what's wrong and how to fix it. 2500 employees were being paid but wasn't able to work... With customers in front of them with money to spend and no time to lose.

Took me 3 hours. It wasn't a lazy mistake... Just a mistake with no easy way to notice while doing the usual post-update quick tests to make sure it runs fine. We had Gui code running code against a training database while the usual business logic was being executed on Unix and production.

Don't need a math genius to compute that a silly DBA mistake was costing more than his annual salary every few minutes.

Mistakes happens but folks, if a few minutes of added work is the root cause of one, time to leave the seat to someone else I'm afraid. No shame there, it's simply a job that requires that mindset and some people needs decades to eventually get caught off-guard and realize it. Nothing is very fun about spending precious time triple checking a 99.9% safe update...nobody will notice the added effort next Monday as it will work regardless as usual. Everybody will yell if it's not working, your fault or not.

My mutli-million mistake never ever got mentioned once it was solved. Everyone knew very well that I can count lost cash and that I've never cut corners for any reason during my whole career. It's still only money... I could now go with the mistake that almost killed 2 youngs workers lifes a few years later.

Stress and way too many hours, it can le ad to a reflex F1 and kill mechanics working in some automation device.

Stay safe with that keyboard guys, it's serious business ;)