Stonefield Query supports versioning of data dictionary objects. This is useful if tables and fields were added to or removed from the database between versions and you have some users using an older version and some using a newer version but they're all using the latest version of your customized Stonefield Query. To prevent users from selecting tables and fields that may not exist in their version of the database, you can specify the version number for each table and field that doesn't exist in all versions. The DataEngine.GetObjectVersion script allows you to tell Stonefield Query what version a particular table or field is at in the user's specific database. Tables, fields, and relationships all have a Version property you can fill in manually. You can also specify what version number to assign tables and fields in the Add Database dialog and what version number to use for new tables and fields when you refresh the data dictionary.

Versioning starts with the Version properties of tables, fields, and relationships. A blank value means the object is not versioned: it appears in Stonefield Query regardless of the version of the database. For an object that isn't available in every version of the database, enter the version number followed by "+" to indicate the object appears in that version and higher versions and should not appear in lower versions (that is, the object was added in that version), "-" to indicate the object appears in that version and lower versions and should not appear in higher versions (that is, the object was removed in the next version), or no suffix to indicate the object appears only in that version and should not appear in any other version. For example, "5.3+" indicates the object is available starting in version 5.3 while "5.3-" indicates it was removed in version 5.4.

The next step is telling Stonefield Query which version a particular table, field, or relationship is in the user's selected database. You do this by creating a DataEngine.GetObjectVersion script. This script is passed three parameters: a reference to the SQApplication object, the name of the data object, and the type ("table," "field," or relation"). The code for this script should determine what version the specified object is in the user's selected database and return that version number as a string. The reason this script is called for individual tables, fields, and relations rather than the database as a whole is that some applications have different versions for different objects. For example, someone may be using Version 5.5 of the Accounts Receivable module but version 5.4 of the General Ledger. If your application doesn't have separate version information for different data objects but just one for the entire database, you can disregard the last two parameters passed to the script and just determine and return the version number for the database. See the DataEngine.GetObjectVersion topic for some sample scripts.

Here's how this works: when the user opens a database (either when Stonefield Query starts or by selecting the Open Database function in the File menu), Stonefield Query loads the data dictionary. Once that's done, it then goes through all objects in the data dictionary that have a non-blank Version property, calls DataEngine.GetObjectVersion for each one, and compares the two versions. It removes the object from the in-memory (not on-disk) copy of the data dictionary if:

• the data dictionary version number has a "-" suffix (meaning the object is available in the specified version or earlier versions) and the database version number is greater than the data dictionary version number;

• the data dictionary version number has a "+" suffix (meaning the object is available in the specified version or later versions) and the database version number is less than the data dictionary version number; or

• the data dictionary version number has a no suffix (meaning the object is available only in the specified version) and the database version number is different than the data dictionary version number

Thus users cannot select tables and fields that don't exist in their selected database when they create a report.