4D v11 SQL features stronger linking between the files that make up a database. In particular the structure file and data file are now linked with a Universally Unique Identifier (UUID). A UUID is a globally universal identifier; no two will ever be unintentionally the same (with reasonable certainty). This adds another layer of security to 4D databases since it is not possible to use a "can-opener" structure file to open any given data file.
This feature behaves similarly to the WEDD resource found in previous versions of 4D. It prevents the structure file from opening data files to which it is not "linked", and vice versa. In fact the WEDD resource is completely redundant in 4D v11 SQL. This "linking" is now mandatory in all databases. As of 4D v11 SQL Release 3 (11.3) the WEDD preference has been removed.
For databases being converted to version 11, the UUID is assigned at the time of conversion. It cannot be changed. It is important to understand this design, especially of development still occurs in the previous version of 4D. Here are some things to be aware of:
- A version 11 structure file can open multiple data files, as long as the UUID matches. Remember, the UUID is assigned at the time of conversion.
- The structure file and data file can be converted independently. More particularly, you can convert the structure file, make your changes, send the new database to customers, and they can open and convert their existing data files. The customer's data file will be linked to the structure file at that time.
- A given data file cannot be opened by different structure files. Note that by "different structure files" this means structure files with a different UUID, not different copies of a structure file with the same UUID, e.g. a development copy, testing copy, and live copy. As long as the UUID matches everything will work.
- The primary circumstance where a structure file will be unable to open a data file is in the case of multiple conversion. For example:
- A 4D 2004 database is converted to version 11. This includes the structure file and data file. At this point a UUID has been assigned. We will call it UUID A.
- Development continues in 2004.
- Data entry continues in 11.
- Thus it is desirable to combine the structure changes in the 2004 database with the data changes in the version 11 database.
- At some point the developer decides to convert the database again, because changes have been made in 4D 2004. Once again a UUID will be assigned to the database. We will call it UUID B.
- This scenario must be avoided!!! The structure file with UUID B will be unable to open the data file with UUID A. It is completely irrelevant that, for all intents and purposes, these are the same database. The UUIDs do not match, so the files cannot be used together.
- There are several solutions to this scenario:
- Discontinue development in the previous version of 4D. There are many powerful and easy to implement features in 4D v11 SQL and the faster they are implemented the faster the power of version 11 can be harnessed. This avoids the multiple conversion issue since the older database need no longer be converted.
- Continue development in both versions. This solution allows the developer to continue support for the previous version while jumpstarting development in 4D v11 SQL. This also avoids the multiple conversion issue since the older database need no longer be converted. This is the preferred solution if development in the previous version is absolutely necessary.
- 4D v11 SQL Release 3 (11.3) introduces a feature to support multiple conversions of a single structure file. In 11.3, whenever a database is converted, a file is created called "Catalog.xml". If the database is to be converted again, this file should be placed next to the structure file *prior to conversion*. This will ensure that the reconverted structure file contains the same UUID as the previous/original conversion. It is very important to keep track of the "Catalog.xml" file. If the file is lost, it will be impossible to reconvert the structure file and maintain the same UUID.
If you're interested, we offer an online upgrading class that covers many of these upgrade scenarios (along with this one):