-----Original Message----- From: Gus Bjorklund [mailto:gus@progress.com] Sent: Tuesday, 8 June 1999 8:43 To: peg@peg.com Subject: Re: CRC on database neilm@young-america.com wrote: > > Talked to Gus at Conference. These problems will NOT 100% go away with > v9.1! They are moving TOWARDS them going away. But until you here such a > statement in black and white from PROGRESS, assume you will continue to need > the 3 db rule to maintain CRC compatibility - and using the .df load method. > I was being a bit conservative. We have actually done quite a bit. Let me recap what we have done so far (as of 9.0B). 1. Index definitions are not part of a table's CRC anymore. If you create a new index on a table, its crc will not change. If you delete an index, the table's crc will not change. An application may not work anymore if you delete an index it was using, but adding an index will not cause a recompile to be needed. On the other hand, the application will not know about the new index. 2. Indexes have their own crc. Changing an index definition will cause its crc to change, and that will require a recompile. 3. We have separated a table's logical column layout from its underlying physical layout. A table's crc is computed on the logical layout. This has the following benefits: * when you make a schema change to a table, we don't have to change underlying data stored in the database right away. This means that schema changes can be done quickly independent of the amount of data stored in a table. The transactions that update the schema can be pretty small and fast. * Since the crc is on the logical column layout, it does not matter how this differs from the physical layout. The crc can be the same no matter what order incremental update operations occur in, as long as the data types and positions end up matching. 4. We dump all the relevant information to .df files. In particular, a field's record position is dumped now, and can be set on a load as long as there are no conflicts like two fields with the same position. 5. When you make an incremental .df, changes to the position are dumped. To illustrate what can be done, consider the following sequence of schema changes (all done with 9.0B on Solaris): 1. I make a copy of the sports database and call it sports1. The initial crc of the customer table is 48132. 2. I delete the address field of the customer table. The customer table crc is now 65021. 3. I add a new address field which ends up at position 18 in the customer record. The customer crc becomes 631. 4. I do an incremental dump and produce delta.df1. 5. I create a new copy of the sports database in sports2. The crc of the customer table is 48132, as before in step 1. 6. I apply the incremental delta.df1 to sports2. The customer crc is now 631, same as in step 3. No big surprise yet. 6. Now I go back to sports1 and add a new integer field new1 to sports1. 7. I generate a new incremental dump delta.df2. It contains an add for new1. 8. I add another new field new2, character, to sports1. 9. I generate a new incremental dump, delta.df3, which contains an add for new1 and for new2. At this point, the crc for the customer table is 37584. We have now made 4 changes from the original sports: delete original address field, add address field, add field new1, add field new2. 10. Now I go back to sports2 and apply the incremental df delta.df3. The customer crc is 37584. No surprise here because I applied two incrementals, delta.df1 and delta.df3. 11. Now I create a new database sports3 from the original unmodified sports. The customer table crc is 65021. 12. I apply delta.df2, which adds new1 to sports3. The customer table crc is 18162. 13. I delete the field new1, which just got added. The crc is 48132. 14. I apply delta.df3, which adds fields new1 and new2. The crc is now 19672. 15. I apply delta.df1, which updates the position of the field address to sports3. The customer crc is now 37584. This is the same value I got for sports2 in step 10 above. But the order in which the changes were applied to sports2 and sports 3 is different. For sports2, we applied delta.df1 and delta.df3. For sports3, we applied delta.df2, updated the schema to delete the field it added, then applied delta.df3, and then delta.df1. What we have not done yet: ========================= You can't set the position field in the dictionary. We have not done enough testing. We have not updated the documentation adequately. We may have forgotten something. > -----Original Message----- > From: Wim van der Ham [SMTP:wvanderh@inrete.it] > Sent: Wednesday, June 02, 1999 11:40 AM > To: peg@peg.com > Subject: Re: CRC on database > > At 12.05 02/06/99 -0400, Huse, Dana wrote: > [snipped home work excercise] > > Of course it's only a matter of time and all these problems will > dissolve > when everybody is running on V9.1 or higher where .df files contain > ALL > information that is used in CRC calculations. > > Till then, > > LISTEN TO WHAT THE GUY SAID ;-) > > Ciao, > > Wim > _________________________ > Design, Development, Training > and Implementations in Italy. > > Tutto in Progress(r)! > > Wim van der Ham > Tel: (+39) 011-4527691 > GSM: (+39) 0335-6877283 > E-mail: wvanderh@inrete.it -- regards, gus **************************************************************** Gus Bjorklund, Progress Software Corporation, Bedford MA. Purveyors of the finest rdbms on the third planet from the sun. "In theory, there is no difference between theory and practice, but in practice, there is." - Jan L.A. van de Snepscheut ****************************************************************