corn

The one area where I think the FileMaker security model could be improved in by implementing an inheritance model. Often times I want one Role to have access to "A", a second Role to have access to "A" + "B", and a third Role to have access to "A" + "C". If defining "A" is complex, doing it three times introduces the possibility of error between the three implementations. Furthermore, if I add new functionality that users with access to "A" should have access to, I need to add that access to three places instead of one. Otherwise I agree, most people who "role their own" don't need to. One thing I would add to this is the use of Extended Privileges which both can allow you to define security in a less granular way and the management of which can be delegated to trusted users. This might be useful to GisMo as a way of "rolling your own" but doing so within the FMP security model.

No, because as soon as you leave X you'll be prompted with the warning before you've had a chance to enter a value in Y.

For argument's sake, let's presume it was "safe" to do so. What would you then have in the backup? Worthless FMP files. Since FMS holds some of the data in cache, there is a pretty good chance that the files that are in the backup will be corrupted. So, even if you could backup these live files, it's not worth doing. And since our initial scenario is not true, and there is some chance of damage when backing up an open FMP file, you're essentially increasing the risk of corruption with zero potential benefit.

10,000 loops would take an indeterminate amount of time. You could capture the start time and then loop until a specified number of seconds had passed, however you're not going to be happy with that approach. FMS performance will degrade noticeably while it's doing "nothing."

FileMaker might not give it to you, but you can have it with a plug-in such as Fusion Reactor.

No custom function necessary. Use the FieldName() function but instead of a layout name for the second argument, supply the table occurrence name (making certain there is no layout with the same name).

This is a very tricky subject. What you have essentially is a location which can be comprised of other locations, which in turn can be comprised of still more locations. It's a recursive data structure and they're easy to implement but difficult to work with in FMP, typically because layouts aren't dynamic. Depending on what you want to do with these locations, you can either create specific tables for each location type, or you can use a single table and configure a recursive relationship between the table and itself. Using some of the techniques available elsewhere you can present recursive data structures as a collapsable tree structure.

Well, considering that they are "object" triggers they may in fact be a bit less reliable since they are tied to your interface, not to your data. In FMP 10 we still have the problem of the "rogue" interface file that bypasses any script triggering mechanisms. The disadvantages of the plug-in methods are that they require the plug-in to be installed at the workstation and, in the case of script triggering plug-ins, they run "post-event." The first problem can be addressed rather easily, the second not as well.

Sorts don't use the index although Finds do. Since I am explicitly saying the "Name" field in PARTY is an "identity" field that means I would have it stored and indexed. The operative concept here is that this Name field can be modified independently of the various name fields stored in the subtype. If this is not desirable in your situation then an auto-enter calculation can work for you. You might consider using a script triggering plug-in like ZippScript to force a re-calc of the PARTY::Name field when any of the other name fields in PERSON or ORGANIZATION are changed. Alternatively you can use a SQL plug-in to modify the PARTY::Name field in the same way (this is pretty cool, no scripts needed to update related data but if the record is locked, the update doesn't happen).

I think what you're getting hung up on is the idea that either the Full Name should be derived from its constituent parts (e.g. First Name, Middle Name, LastName) or that the individual name fields should be derived from the Full Name. What I am advocating is that the two are stored separately - "Full Name" in PARTY and FirstName, MiddleName, and LastName in PERSON. Likewise in ORGANIZATION you might have attributes specific to organizations (like it's legal name) but it's "Full Name" is also stored in PARTY. I hesitate to use the term "Full Name" here since it is a fuzzy term (and in my models call the attribute "Name" only) but I think you know what I mean. That is NOT to say that your data entry forms and methods should force the user to enter data twice. On the contrary, you should make data entry as convenient as possible while encouraging quality data. So if you want to capture FML as separate fields by all means do so, and automatically calculate the "Full" name to be stored in the PARTY table as a convenience. But... you should provide a mechanism by which they can change the Name in the PARTY table to something meaningful. So if they have two "Joe Wurzelbacher" records they can modify the name to better distinguish them. One might be 'Samuel "Joe the Plumber" Wurzelbacher' while the other is 'Joe Wurzelbacher Sr.'. Which is also to say, you should have fields specific to the purpose for which they're needed. For example, if you need "addressee" or "formal salutation" fields you should create and label them as such. When someone asks for "First Middle Initial Last" I ask them how they intend to use it. More often than not the intent is as an addressee field so that's what I give them. I have other fields that are used literally for filing - for example a "File As" field that might contain 'WURZELBACHER, Samuel Joseph (Joe)'.

If you're truly sorry for ranting then don't rant and then you won't have to be sorry. The names issue is precisely the problem here: of what use is the Party supertype if it contains no attributes. More specific to FMP, how do you display anything meaningful in a portal of Party records if all of the attributes are located in the subtype tables and the portal contains a mix of subtypes? The obvious answer is to store an attribute - you can call it "Foo" but I'm going to call it "Name" - in the Party supertype table. This name will identify a particular party, whether it be a company, a person, or perhaps an aggregation of people. Here's where the "cultural construct" comes into play. Because of a Western bias we tend to think of names as "first middle last" and that there is this thing called a "full name" that can be constructed from "first" + "middle" + "last". It's a lie I tell you. Let's take a real person, 'Dr. Phil'. His full legal name, should I need to store it, is 'Phillip Calvin McGraw'. Now there is some question here - do we store that as 'Dr. Phillip Calvin McGraw, PhD' or do we keep the honorific and titular attributes separate? Meanwhile he is more commonly known as 'Dr. Phil' in most situations - should we just store that as the "full name?" All these names and what to do... But that's exactly my point. If you only have a view of names as being "first middle last" then storage of the so-called "full name" becomes a problem because you tend to see it as a derivation of the separate attributes. Once you see that "first middle last" is just one of many different naming conventions and that they are insufficient for composing many of the names you will need to actually use in your system you will find, I believe, that storing a "Name" attribute in the PARTY table is the least of your worries.

I didn't say that you shouldn't have some mechanism by which to facilitate data entry, but that is a tangential issue compared to the modeling of the data. I go back to the idea of a "PreferredName." In the data model it is a separate attribute from "FirstName" or "GivenName" or what have you. At the same time the assumption is that unless specifically stated otherwise we can assume the "FirstName" is also the "PreferredName" and can use data entry techniques (auto-enter calculation, scripted process, script trigger, etc.) to facilitate this. It's a similar concept to that of web checkout forms that allow you to say your shipping address is also your credit card billing address. They present a simple mechanism to help you avoid double-entry of data but that's not necessarily indicative of how the data is stored on the back end. FMP makes it difficult to separate the collection and presentation of data from the underlying storage of data. At the same time, however, I don't believe that additional effort is significantly more than the effort required in other systems. On the contrary, I think what FMP excels at is making it incredible easy to create both simple and complex database applications with its tight data/interface binding. Unfortunately for most systems in the case of the latter it often comes at the expense of being poorly modeled and therefore susceptible to problems down the road.

This has nothing to do with political correctness but rather why I believe most people fail to see the distinction between a "Name" - which all Parties have - and the other attributes specific to the subtype. If you think only of First Middle Last then it's a simple mistake to think of "John Sydney McCain" as data derived from First = "John", Middle = "Sydney", and Last = "McCain". It's only when you're confronted with names that don't fit the model that you start to consider that the full name perhaps isn't always derived from three constituent attributes. Having dealt with all manner of names I have come to realize that the commonality between them is most likely "Family Name" and "Given Name(s)". Moreover, the names you mention are different attributes of the contact. The "salutation name" and the "informal" or "preferred" name need not be composed entirely of the legal name components. A constituent in a fund raising system might be named "John Patrick Deval" but prefers to be addressed as "JP" on all correspondence. And you can bet that if "JP" is a big donor "JP" will be addressed how "JP" wants to be addressed, despite the derivation rules you setup in your system. Many people setup a system of calculated fields with "override" fields that allow one to change the default derivation behavior but this is simply an implementation variant of the true rule: other "name" attributes for people are usually, but not always, related to the other name attributes in the system. The point being, "Name" is not derived in the Party model and is therefore suitable to be physically implemented in the PARTY table as an attribute common to all Party types and subtypes.

Wow! Look at the party I was missing. I suppose better late than never. You must be from the US, right? Because "First Middle Last" is a very US-centric view of names that will lead to this confusion. If, on the other hand, you took a more international view of names you would find that construct lacking. Take my friend "Manuel Luiz Rodrigue Jesus Ponce de Vega." Or my other friend "Viet Tran." The descriptor both of my friends have in common is their "Name." Which part of the name is "first" or "last" or "given" or "family" or "christian" is a cultural construct. As such, I would most certainly store "Name" as an attribute of the Party table which addresses the "WHO" part of "WHO is the party we are referring to." I hope my answer is clear in so far as "Name" is stored in the PARTY table, and contains the full name that identifies the party in question. Attributes that are not general to the party belong in the subtype tables. The reason the model isn't used more is because of unfamiliarity with the model and those who do know about it don't necessarily understand it. But that's not just FileMaker - the same is true of just about every other RDBMS out there.

100 characters per documentation; 109 characters in observation You should look into Ray Cologon's UID technique available on his website which can help create unique keys.