Post-Conversion Tasks

Post-Conversion Tasks

As discussed in the previous sections, you can avoid many potential post-conversion problems by doing some pre-conversion work on your old system. However, a number of tasks can only be done post-conversion.

NOTE

The actual tasks vary from system to system; many of the tasks listed here may not be applicable to your particular solution.

You should begin a list of post-conversion tasks during your exploration of the alpha files. You'll spot problems and potential areas of improvement. Anything that can't easily be fixed through pre-conversion work should go on your post-conversion task list. Keep in mind that you'll end up destroying the alpha files, so don't spend too much time or effort fixing problems. Some fixes are necessary just so you can continue your exploration; you may opt to do other fixes just so you can test out the results.

To know what tasks you'll need to do after conversion, you need to understand what actually happens to your files during conversion. The following sections look at five different aspects of your files: security, relationships, scripts, fields, and data. For each, we discuss what happens during conversion and what potential post-conversion tasks you need to perform.

TIP

One vital post-conversion task that goes almost without saying is testing. Before deploying a converted solution, it's vital that you do sufficient testing to identify any problems.

If your databases don't open correctly immediately after conversion, see "Disabling Startup Scripts" in the Troubleshooting section at the end of this chapter.

Security

Depending on whether and how passwords and groups were set up in your solution, you may have some post-conversion work to do involving security. During conversion, passwords in your previous system are turned into accounts, and groups are turned into privilege sets. Accounts in FileMaker Pro 7, of course, have both an account name and a password. For each account in a converted system, the account name and password will both be the same as the old password. So, a password of "test123" in your old system turns into an account named "test123" with a password of "test123."

Post-conversion, you should change all the account names to something other than their default conversion value. Account names are visible on screen during login, so if you don't do this it will be very easy for people to discover their co-workers ' passwords. Be sure you distribute the new account information prior to deployment.

The conversion of groups into privilege sets is more complex than the conversion of passwords into accounts. The number of privilege sets may be more or less than the number of groups in the old system. The following list explains the rules for determining how groups relate to privilege sets:

• If there are multiple groups with identical settings, only the first group is converted and the others are discarded.

• If there are passwords not assigned to any groups, new privilege sets are created based on the properties of the passwords. The first one is named "Privilege Set," the second "Privilege Set 2," and so on. Any passwords with the same properties are assigned to the same privilege set.

• Any groups not assigned to any passwords (other than master passwords) are not converted into privilege sets.

• If a password is assigned to multiple groups that have different access privileges, a new privilege set is created that has the privileges of both groups. The name of the privilege set is a combination of the names of the groups used for its formation. For instance, if a password "foo" was associated with groups "bar" and "baz," each of which had different access rights, the new account named "foo" would be associated with a privilege set named "bar/baz."

• Master passwords are associated with the "[Full Access]" privilege set.

TIP

The Status(CurrentGroups) function is turned into Get (PrivilegeSetName) during conversion. However, if the function tests for the presence of literal text strings, you may need to change the strings to the new privilege set names; these aren't modified at all during conversion. For instance, if you used PatternCount (Status (CurrentGroups), ("masterGroup")) in a script or calculation formula, after conversion you need to manually edit this to be Get (PrivilegeSetName) = "[Full Access]" . Because accounts can be associated with only one privilege set (whereas passwords can be associated with multiple groups), the PatternCount function is no longer needed.

Default Passwords

If you specified a default password in the document preferences in your old file, the converted solution has a default account specified in the File Options. As in previous versions of FileMaker Pro, you can force the account/password dialog to be shown by holding down the (Option) [Shift] key as the file opens.

(no password)

Previous versions of FileMaker allowed you to specify a blank password as a valid way of gaining access to a file. As shown in Figure 18.6, this is represented in the password list as (no password) . During conversion, a file with a blank password has the Guest account activated. It is associated with whatever privilege set is appropriate. When the Guest account is active, in the login dialog, users have the option of selecting the Guest Account radio button. It is grayed out if that account isn't active.

Figure 18.6. In previous versions of FileMaker Pro, you could specify no password as a valid password.

Files with No Password

If you convert a file that has absolutely no passwords in it, the converted file has an account named Admin with a blank password. It is assigned the [Full Access] privilege set, and is set as the default login under F ile, F ile Options. This is shown in Figure 18.7. A guest account is created as well, but it is inactive.

Figure 18.7. In the File Options dialog, you can specify an account to use as a default login.

Extended Privileges

If a file is set to be Multi-User or Multi- User (Hidden), all the privilege sets will have the fmapp extended privilege enabled when it is converted to FileMaker Pro 7. This is required for accounts to be able to open files hosted by FileMaker Server or shared peer-to-peer. You can certainly enable or disable this extended privilege after conversion as fits your deployment needs.

Relationships

During conversion, relationships are turned into table occurrences. For instance, if you have a relationship from File A to File B called "File B by someKey," when you convert these files, the Relationships Graph for File A will have an external table occurrence called "File B by someKey." The number of table occurrences in the converted file will be equal to the number of relationships in the old file. Settings from the relationship, such as cascading delete and the ability to add records through the relationship, will be retained in the converted solution.

As illustrated previously in Figure 18.1, the Relationships Graph in a converted solution is always in a hub-and-spoke configuration. The hub is a table occurrence associated with the file's base table; it is named the same as the table (and the file itself). All the other table occurrences are connected to the hub as spokes are connected to a wheel. All the layouts in the file are associated with the hub table occurrence, which means that it is always the context for all scripts, calculations, imports, and exports.

NOTE

Remember that each file in a relational solution is turned into a file in FileMaker Pro 7 during conversion. Each has its own hub-and-spoke Relationships Graph.

If you plan on doing any future development in your converted system, you'll likely want to spend some time organizing the Relationships Graphs. This may simply mean repositioning and resizing table occurrences to make particular relationships easier to locate. You might also consider using color as a means of organizing the graphs. Finally, depending on what sort of conventions you used to name your relationships, you may want to change the names of the table occurrences to better reflect their purposes.

Down the road, consider making some more significant changes to the converted Relationships Graph. Many of the relationships from previous versions of FileMaker either could be implemented differently or are not required at all in FileMaker Pro 7. For instance, many developers used relationships based on constants as a means for setting and retrieving global field values from other files. In FileMaker Pro 7, fields with global storage can be accessed from any table occurrence, even ones disconnected from the current context. Likewise, relationships built with multi-line and/or concatenated keys could be built in FileMaker Pro 7 with join types other than equi-joins and/or multiple match criteria. These aren't changes you need to make prior to deployment, but they do make the converted solution easier to maintain and extend in the long run.

Scripts

Many script steps in FileMaker Pro 7 have slightly different parameters or behavior than in previous versions, and as such, you need to be vigilant in regard to a few potential post-conversion issues. The conversion routine actually adds steps to your scripts in some cases as a way to compensate for functional changes.

Some of the changes, and the issues that arise from them, include the following:

• The Go To Layout script step no longer has an option to Refresh Window. If you had checked this option, a Refresh Window script step is inserted during a conversion, directly after the Go To Layout step.

• The Refresh Window script step no longer has an option to Bring to Front. A Select Window [Current Window] step is added to scripts that had this option specified. This can cause some extra "screen flashing" in some instances, so you may need to remove Select Window steps to achieve the behavior you want.

• The Perform Script step no longer has the option not to perform sub-scripts. This was a feature that was infrequently used, so chances are that you won't miss it. In FileMaker Pro 7, sub-scripts are always run. The conversion routine does nothing to account for this, nor does anything in the conversion log alert you of any Perform Script steps where the sub-scripts button was unchecked. If this was a feature you relied on in your solution, you may need to rework some of your scripts during post-conversion testing.

• In previous versions of FileMaker, when an external script was called as the last step of a script, the external file's window would become active, having the effect of "leaving" the user in the other file. The same holds true of Go to Related Record steps. That's no longer the case in FileMaker Pro 7. To accommodate this change, the conversion routine inserts a Select Window step following certain Perform Script and Go to Related Records steps. If a script ends with a call to an external subscript or with a Go to Related Records step, the conversion routine adds a Select Window [Name: "NameOfOtherFile"] . When these steps are not found at the end of a script, a Select Window [CurrentWindow] is added. The selection of another file's window, however, can be a bit fragile because the name of the window is hard-coded as the filename itself. If no window by that name exists, control isn't passed properly to the external file. You may need to edit the Select Window steps ”or perhaps even delete some of them ”for your script to function as it did previously.

• There is no longer a Show Message script step in FileMaker Pro 7. During conversion, it is changed into a Show Custom Dialog step. The default title of the dialog is simply "Message," and the message itself is the text of your old script. You need to make no post-conversion changes to these; simply be aware of the change that occurs.

• The settings stored on the Windows operating system for Print and Print Setup script steps may not convert properly. Be sure to test, and if necessary re-specify, the print settings after conversion. It may help to go back to your previous solution and take screen shots of the settings stored for particular scripts so that you can easily restore them post-conversion.

• The Open File script step in FileMaker Pro 7 always activates the file being opened. In previous versions, the Open script step would do this only if it were the last step in the script. Any additional steps would cause the calling file to remain active. For example, say you have a script in File A that has two steps: Open ["File B"] and Exit Record/Requests . When performed in a previous version of FileMaker Pro, File A would remain the active file throughout the script. To retain this behavior in FileMaker Pro 7, you need to add a Select Window [Current Window] after the Open File script step.

• FileMaker Pro 7 requires much greater attention to the opening and committing (saving) of records than previous versions did. Consequently, some of your scripts may require some post-conversion tweaking so they behave as desired. For instance, if a script ends with a step that modifies a record, such as a Set Field , the record isn't committed when the script ends. This may cause users not to see "refreshed" data until they manually commit the record. If the script in question was called as a subscript, there may be other unintended behaviors because the edited record would still be locked. The fix for this is to add a Commit Record/Request step at the end of any script that modifies data.

  NOTE

  Because Exit Record/Request converts into Commit Record/Request , you can also fix many of these problems as pre-conversion tasks.

  
  

• In previous versions of FileMaker Pro, the Go to Field step would generate an error if the record was locked, so it was common to use this step as a test in scripts that needed to be able to modify records. In FileMaker Pro 7, simply entering a field no longer attempts to place a lock on a record, so it doesn't generate errors that you can rely on. You should therefore find and change any Go to Field step that serves this need into an Open Record/Request step (which does explicitly try to lock the record).

• FileMaker Pro 7 handles summary field sorting differently than previous versions of FileMaker Pro did. Instead of being able to specify only a single summary field as one of your sort criteria, in FileMaker Pro 7 you can re-sort any number of sort criteria based on summary fields. During conversion, scripts that store sorts that include summary fields are altered so that the summary field is attached to the last non-summary field in the sort criteria. For instance, say you have a summary report of customers and invoices where you sort by CustomerName , then by InvoiceDate , and finally by TotalInvoiced (a summary field). Your report would not list customers alphabetically , but rather from lowest to highest, based on the total you had invoiced. After conversion, your script's sort would have two criteria: CustomerName and InvoiceDate . The latter would be reordered by TotalInvoiced . You would need to manually adjust the sort criteria so that the TotalInvoiced summary was applied to the CustomerName field rather than InvoiceDate for your report to display the way it did previously.

• In previous versions of FileMaker Pro, after sorting a set of records, the active record was always the first one in the sorted set. In FileMaker Pro 7, the active record is whatever it was prior to sorting. Because this could have adverse impact on scripts that expect to be on the first record after a sort, a Go To Record/Request/Page[First] step is automatically added after every Sort script step during conversion.

• If you've specified scripts to execute when a file opens or closes , these preferences are retained in the converted file. Be aware, however, that they may be triggered at slightly different times in FileMaker Pro 7. Startup scripts execute the first time that a window for a particular file becomes visible. For instance, if File A has relationships to File B, when File A is opened, File B appears in the list of hidden files in parentheses, meaning that there are no windows for that file, hidden or active. If you were to select that file from the list, the startup script for that file would run. Shutdown scripts run when the last window for a given file is closed. The Close File script step closes any windows for that particular file, thereby triggering the shutdown script. In both of these cases, however, if files that have relationships to the file you just closed are still open, the file name still appears in the list of hidden windows in parentheses. Thus, a file is not truly closed until all files that reference it are closed as well.

Fields and Formulas

There are some subtle (and some not so subtle) differences in FileMaker Pro 7 regarding fields and formulas. As with scripts, you'll find that the conversion routine does a good job at heading off many problems by modifying your code a bit. Still, a few things can go awry in a converted solution that you'll need to deal with during post-conversion testing.

• FileMaker Pro 7 has new reserved words that didn't have the same significance in previous versions. For instance, "Bold" and "Italic" are potential parameters in the new TextStyleAdd and TextStyleRemove functions; you would be warned in FileMaker Pro 7 that these are illegal file names. If you used any reserved words or illegal names in your old system, anytime they were used in calculation formulas they are enclosed , upon conversion, with the symbols ${ } to avoid confusion with the reserved words. A field named "Bold" in your previous solution would appear as ${Bold} in formulas in FileMaker Pro 7. The conversion log also lists this as a "Poor field name."

• FileMaker Pro 7 uses a new shortcut evaluation method to speed up the processing of calculation formulas. This can cause problems in a converted system if you were relying on every portion of a formula being evaluated. As an example, say you have the formula If (Length(myField) > 10 and Left (myField, 1) = "X", 1, 2) . When FileMaker evaluates the first part of the test, Length(myField) > 10 , if that does not return True, then it doesn't bother evaluating the other half of the test. It immediately knows that the False result must be returned. In previous versions of FileMaker, external function calls to plug-ins were often placed in innocuous places in functions; it's possible they may not be invoked after conversion to FileMaker Pro 7. For instance, in the formula If ( 1 or External ("myPlugin", "someParameter"), 1, 2) , the plug-in would never be invoked because the first part of the test is sufficient to establish which value should be returned.

• The Today function is no longer supported in FileMaker Pro 7. During conversion, references to Today in scripts and validation checks are converted into Get (CurrentDate) . If it's used in stored calculation fields, a new date field called Today is added to your database; it is set to auto-enter the creation date. Additionally, a new script called Update Today Field is added to the file; it's shown in Figure 18.8. This script is set as the file's startup script, or, if it already has a startup script, that script is modified so that it calls the Update Today Field script as its first step.

  Figure 18.8. The conversion routine automatically adds this script to your file if you have fields that use the Today function.

  
  

• The results returned by DatabaseNames and Status(CurrentFileName) included file extensions in previous versions of FileMaker Pro. In FileMaker Pro 7, DatabaseNames and Get (FileName) do not return file extensions. You may need to edit scripts and fields that presume the presence of a file extension. For instance, you might check to see whether a file "foo.fp5" is open by using the formula PatternCount (DatabaseNames, "foo.fp5") . This formula always returns 0 in FileMaker Pro 7. Be aware also that no existing data is affected during conversion. If you have a field that auto-enters the results of Status (CurrentFileName) into the field (or even a stored calculation with the same formula), then after conversion all your data will still contain a file extension, but any new data you create won't. This sort of inconsistency should be avoided; it may have adverse consequences down the road.

• The indexing rules have changed slightly in FileMaker Pro 7. For instance, non- alphanumeric characters weren't indexed in previous versions but are in FileMaker Pro 7. One of the consequences of the new indexing rules is that hyphens are considered word breaks for the first time. For instance, WordCount ("testA-testB") returns "2" in FileMaker Pro 7 but only "1" in previous versions. Some text parsing routines may need to be changed to account for this.

• Alphabetic characters, spaces, colons, and plus signs are not acceptable separators in date fields in FileMaker Pro 7. If your previous files use any of these as separators, your converted dates will be invalid. You can test for invalid dates after conversion by doing a find for ? in date fields. You can clean up invalid dates using a calculated Replace that uses the Substitute function.

• Previous versions of FileMaker interpret text strings placed in a number field one of three ways. If the text string begins with the letters "Y" or "T" (representing "Yes" and "True"), it is considered to have a value of 1. Text strings beginning with an "N" or "F" (representing "No" and "False") are considered to have a value of 0. With any other starting character, the value is considered blank. In FileMaker Pro 7, all text strings are regarded as having no numeric value. Frequently, developers captured Yes/No radio button responses in number fields, knowing they could perform math as if these were 1 and 0. In a converted solution, any formula that relies on this behavior returns incorrect values. You can either edit these formulas so they explicitly regard "Y" and "T" as 1 and "N" and "F" as 0, or you can perform a Find/Replace action to modify your legacy data.

• With the exception noted in the previous bullet, text placed in number fields was ignored by previous versions of FileMaker Pro. If, for instance, a number field called myNum contained a value of "23 skidoo", then Length (myNum) would return 2. In FileMaker Pro 7, text functions recognize text characters found in number fields, so this function would return 9. To correct for this, all number fields used as parameters in text functions are wrapped with a GetAsNumber function, which strips out any non-numeric characters. Don't be surprised if you see GetAsNumber sprinkled throughout your field definitions after conversion. It may not be needed, but it's a case of better safe than sorry.

• The contents of container fields are preserved during conversion, but depending on what platform you do the conversion, you may have some post-conversion work before they can be displayed properly cross-platform. In previous versions of FileMaker Pro, when the Store Compatible Graphics option was selected in a file's document preferences, both Windows Metafile and PICT images were stored in a single container field. The Windows Metafile data is not immediately accessible if you use a Mac for the conversion. You can restore it by opening the files on a PC and viewing each record with a container field. If, on the other hand, you use a PC for the conversion, be sure that QuickTime is installed or else the PICT data is not preserved.

  TIP

  If you think you may have issues with container fields, be sure that you test your alpha conversion files on both platforms. If it's convenient , perform the final conversion on a PC with QuickTime to avoid this issue altogether.

  
  

• The Mod function in FileMaker Pro 7 handles negative numbers differently than previous versions did. For example, in previous versions, Mod ( “10, 3) would return “1, but it returns 2 in FileMaker Pro 7.