On Nov 9, 2018, at 9:47 AM, Chip Scheide wrote: > Other then having added tables and/or fields, rolling back the > structure to a previous one (say yesterday) is simple and is not a > significant issue. > > If you have added fields and/or tables then there can be issues, > however, I am not well versed in this part of a roll back. I know that > if you simply changed one field type to another, with no other change > to the tables, this type of change is also NOT an issue to roll back.
4D is very forgiving when dealing with a data file that does not exactly match a structure file. If the data file has fields in a table, and your structure file does not have those fields, as long as you don’t load and save a record in that table, the data in the fields is safe. As soon as you load a record from the data file, 4D will compare it to the structure definition for the table. Any fields not defined in the structure file are ignored. Any fields that have a different type (like Alpha in the data file and Longint in the structure file) will automatically be converted as best as 4D can to the type that the structure file defines. If you then SAVE RECORD that record back to the data file you get all these changes. Unknown field’s data is lost, different field types are written back to the data file based on the structure file type. As far as a table in the data file that is not defined in the structure file, it also survives. You can’t access the table because it does not exist in the structure file. But the data stays in the data file. It’s basically orphaned. But, if you were to take that same data file and open it up with another structure file that does have that table defined, then the data is still there and accessible again. That’s the basics. I don’t know of any other database system that implements data files, records and field type changes the way 4D does. It really is a beautiful thing when you have a system that is changing and you are moving around between different versions. The trade off to this “beautiful” system, is performance. It takes extra time with every record load to do the field-by-field comparison and data type conversion if necessary. But with the hardware of today, it’s really a non-issue. No noticeable performance penalty. In the 4D world, any performance tradeoff is easily accepted for the benefits it can provide. Tim ***************************************** Tim Nevels Innovative Solutions 785-749-3444 [email protected] ***************************************** ********************************************************************** 4D Internet Users Group (4D iNUG) Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
