Field Naming Conventions

---

When you export, import or modify layouts within SumWare Consulting's solutions (such as Athenaeum Pro), you might see some apparantly strange field names. Believe it or not, there is method in this abundant madness.

---

Most of SumWare Consulting's projects consist of collections of databases that are related to each other in a variety of ways. To keep track of these, we use sets of naming conventions, as described below. These might appear obscure at first, but when grasped, it is very easy to identify the structure. We name Fields, Files and Relationships according to these rules.

Files

All files are named in a "lowest common denominator" method - with 8.3 DOS file names.

That is, the file names are up to 8 letters with a 3 character extension. For example, "sumware.swc", "contacts.fp3", "pcode.fp3", etc.

Furthermore, all but the main files in a multi-file solution use the underscore character at the end of the first part of the name. E.g. the secondary files in Athenaeum Express are Borrowr_.AEX, Catalog_.AEX, Catarc_.AEX, circArc_.AEX, Circuln_.AEX, help_.AEX and Reserve_.AEX. The underscore ensures that the file names don't appear in the network "open" dialog box when trying to open the solution over the network.

Field Names

Field names within complex solutions contain two parts and appear in the format

x_yyyZzzz

where

x_

indicates which file the field belongs to (important when viewing related data across files)

yyyZzzz

is the name of the field itself, displayed as a single word with no spaces, and each part of the word has an initial capital letter (this is very similar to the smallTalk computer language).

So, in Athenaeum a field in the catalogue would be named "cat_somethingOrOther" and a field in the borrowers file might be called "brw_nameLast". Fields that have similar function are similarly named and are named in a fashion that would cause them to be displayed together when sorted alphabetically. For example, First, Last and Full names in the Borrowers files might be called b_nameFirst, b_nameLast, b_nameFull respectively.

Relationships

Relationships are the threads that tie different sources of data (files) together. And the tie is based on fields at either end. So, in a contacts file, you might have a company code that allows FileMaker Pro to find the details of the company for that contact. When looking at the contacts file, the field that stores the company code might be called c_companyID (which, incidentally, is the primary key). In the Company file, the field containing the company code might be called co_ID (which, in this case, becomes the foreign key).

Relationships are therefore named with the two field names seperated by a period (full stop), but with one condition: the prefix for the primary field (in the current file) is dropped off, because it is redundant.

The above relationship would therefore be named

companyID.co_ID

This might look a little clumsy, but is invaluable when calling on a site with a problem installation. I once called in on a client whose solution I had never seen, but this method had been used, and we repaired their files in 3 minutes.