This brings about the problem of how to synchronize the data squadron wide. Some squadrons pass copies on a master database, but as explained above, this limits the flexibility of the system. A far nicer approach would be as follows:

• Have a single person responsible for keeping the BDU fields maintained by the squadron up to date and making BDU uploads.
• Allow each user to download roster updates from HQ for himself. Alternatively distribute the downloaded roster file itself to other users.
• Utilize DB2000's built in features for updating purposes. For example if a user defined field should be on all users database, export it and pass the exported file for import by other users.
• Make use of the merit mark options and data files. This will be discussed in other parts of this page.

Distributing a master database file can have nasty repercussions.  A true case is reported where the squadron procedure is to pass copies of a master database to other users. When the user responsible for merit marks copied it to his hard drive he overwrote his older version which had contained his MM recommendations. He was understandably upset and created new recommendations from scratch, which took a long time. If he had understood how the database and other data files work he could have easily avoided this.  But first, we see here why this method is bad. When updating is done internally in DB2000, a backup trail is established and older database versions can easily be restored. When you update by copying a database externally, this doesn't happen. In the example sighted, the easiest way to have restored the merit marks would have been to import the MM data file, which is automatically maintained by DB2000. This would have taken just a few seconds. The user obviously didn't know of its existence.

The resulting file is in csv, comma separated value, format. It contains the field description and the field content. If this file is imported into another database, the program checks to see if the field already exists. if not, it creates the field and then fills it from the file content. The certificate numbers in the file are checked against those in the target database. If any of these is not resident then that record is not included.

• Import Options
  • Overwrite existing records. This will import all members in the file that match certificate numbers with members in the target database and will replace any MM recommendation that already exists.
  • Add new records only. This will add recommendations for matching records where there is no current recommendation.
  • Append to existing records.  This will attempt to add any new record to an existing one. Because there is a limit to the number of characters that can be used for a recommendation, if the result is too long, both recommendation will be shown in a dialog from where the user can edit to a final result.
• Add unmatched records as affiliate
  • No. Default condition, don't add.
  • Optionally. This will show each unmatched record on a dialog and allow user to decide. Note: If the file is very large and there are many unmatched records this can get tedious.
  • Automatically. Use this only if sure of the result. Of course you can always delete them again, or not not save the database,

The import "Append to existing" option is very useful for doing cooperative merit marks. If squadron chairpersons each make their recommendations using DB2000 they can export there files and send them to the merit mark chairperson. He can then import the file and build a recommendation from several files where one may not have been sufficient for a valid recommendation.

TIP: My program "Boating Course Assistant", BCA, can make merit mark recommendations for each boating course for those staff members that were present or supported the course. These files can be emailed to the MM chairman for import to the master file. BCA is fully compatible with DB2000. Download from USPS web site.