eos

Lee was asking how you want to use this result within the processes of your solution, not about your ultimate scientific goals. This information may not only let us suggest a better solution, but even maybe a different approach.
 
Anyway, here's a different method to get your desired text result.
Widen_eos.fp7.zip

See if this helps you:
LayoutByChoice_eos.fmp12.zip

Yes; you're only interested in a boolean result to use for your script branching. The expression in the calculation does exactly that: x = y can only be True or False, so there's no need to check on anything else. So your script would start like this:
 
Show Custom Dialog […] // where you prompt and commit the string to compare
If [
Let ( pw = ExecuteSQL ( " SELECT AdministrativePassword FROM Preference " ; "" ; "" ) ; not ( pw = Preference::SearchText ) // True or False ) ] # error dialog # rest of your script   depending on your script logic, use the expression with or without negation, i.e. not ( expression) or expression
 
 
The string "SELECT…FROM… etc." is parameter #1 (the query), "" is #2, and (the second) "" is #3. 

Here's sample file that uses individual date components, rather than the date itself.
 
It's not exhaustively tested, but you should be able to adapt it further as required.
MemorialRemainingDays_eos.fp7.zip

Try
 
not isEmpty ( FilterValues ( Logfield ; portal::property ) )

You can relate Aircraft Hours and Maintenance by matching Aircraft to Aircraft, sort the Aircraft Hours TO descending by date and just look at the date from the first record via that relationship (which is the most recent date), i.e. put in on the Maintenance layout.
 
What you apparently don't have, but should, is a table Aircrafts, with a unique ID for every aircraft. Then each entry in those two other tables can relate to one Aircraft record, and records belonging to the same aircraft will have the same foreign AircraftID.

would break on an empty field … better: Case ( Table::field = 50 ; 100 ; 50 ) ]; 

Well, it's surely possible; here is one method.
 
Note that you could also use a filtered portal, using your search term(s) as filter(s).
Example_eosMOD.fmp12.zip

The first parameter of Substitute () is the text in which you want to perform the substitution. So your source string is only the "s", in which you substitute the search string "s" with "", and the result is an empty string.   Try  Case ( Right ( myText ; 1 ) = "s" ; Left ( myText ; Length ( myText ) - 1 ) ; myText ) if in fact a trailing "s" guarantees multiplicity.

Your nomenclature is giving me a headache,  but I'm pretty sure that wasn't is  … what I actually meant is along the lines of this example:
 
AnalyzeThis_eos.fp7.zip
 
which also shows how you can summarize data for the staff members for the date period (in case you didn't already know …) 
 
Hope this helps.

Define the CF formula for the button as
Count ( Tasks::primaryKey ) > Count ( Tasks::completed )

The formula only "sees" the ID of the first matching record, which may or my not be the ID of your current record. A check on the inclusion of the current ID would include List (), but this would also trigger for unicates. You could combine it with counting the number of matching records, but then this test should by itself be sufficient: 
Count ( Table 2::_kpln__TableID__lxn ) > 1 btw, I changed the data type for Color from 'Number' to 'Text', and the relationship predicate from 'Cartesian' to 'Equals' …
temp_Mod_by_eos.fmp12.zip

Rod -
 
 
… I find that in general, there definitely is something de-tached about you … 
 
 
If you want an infinite loop, just don't specify an exit condition (and make sure the script can be terminated by another mean).
 
Try this; it should take care of the “Accept” part, but I wasn't sure what “Postpone” is supposed to do, and I obviously don't know how the process fits into the larger workflow.
 
Either way, the narrative of the script should be easier to follow …
RingMyBell_eos.fmp12.zip

The procedure works (at least under Mac OS X):
 
TestAt_2013_09_19 5_22_42 PM.pdf
 
The problem is that you're using different $s for creating/appending the PDF and for specifying the attachment. Use $PDFPath for all steps.

Deb –
 
if you want to report on Purposes, do not use a value list and checkboxes (a general rule for data you want to report on!); use a Purpose table to define the Purposes to choose from, and a child table (like you do for notes) to record the purposes for a message encounter. Then create the report in that child table.
 
You need a certain level of granularity, as a brief demonstration will show: imagine your summary comprises 6 messages, each with 3 purposes, for a total of (say) 13 distinct purposes; then you would have to show a summarized list with 13 entries – but you only have 6 message records! If, OTOH, you use a child table, then you will have a total of 18 records with non-distinct purposes, which you can sort and summarize/condense into those 13 distinct purposes.
 
Users can create new purposes (or edit existing ones) by adding records to the Purposes table.
 
Have a look inside this file; there are two scripts: one two create new Purpose records, one to create join table records for the existing checked values in Messages. Of course, you must create those two tables.
CONTACTS Sample_eos.fmp12.zip

Then why are you using it?
 
Anyway, here's the standard method to do what you want to achieve.
test_cByeos.fmp12.zip

I used to be able to read – those were the days … Anyway, here it is again.
Conflict.fp7.zip

Set up the checklist items and their categories as tables; whenever you create a new record, use the checklist table as template to create your actual checklist items in a child table to Solutions.
See if the attached file might help you.
PatientQuestionnaireAsLineItemsV1.3_eos 3.fmp12.zip

Create a value list with the entries A,B,C,D,E, a calculation field List ( PurchaseOrders::Code ), put that on your layout and format it as control style checkbox with the new value list.

No; it is called flawed code, which usually is the fault of the person behind the keyboard.
 
On a related note, how about using something more elegant than a brute force approach? (But if you must, use at least Let() to simplify the whole thing a bit.)
 
Less code = fewer opportunities to make mistakes.
MemberFilter_eos.fmp12.zip

Simplest way to do it is like this (I think …). Beware that this method works with a drop-down, but not with a pop-up, since you cannot capture the value on field entry.
DropAlert_eos.fp7.zip

It looks … artistically … like someone took a FileMaker Sample database and made it worse …  Just kidding (a bit)
 
I think the first thing FileMaker should put in their manuals/documentation is: “You don't have to connect everything to everything else in the Relationship Graph!” (not that you literally could).
 
Anyway – if I understand correctly (which I'm still not sure about): You want to enter a new supply item, then select a Medium, and then, based on that selection, see a list of MediumTypes.
 
If this is so, here are some comments: For this scheme to work, you need a foreign key Medium in MediumType – not the other way around.
 
The field you put on the layout for MediumType was a field from the MediumType table itself, which means that a selection here would alter real data (but rest assured, the previously defined relationship into the table couldn't become valid, so no danger … )
 
If you want to say that a certain item is of certain type, then that's an attribute of the item, and thus needs to be stored with the item itself, aka as a field into the table (if an item could be of several types, then that's another story … anyway). If each MediumType is of one Medium (and one Medium only), then you could simply select the MediumType – the matching Medium is already defined by the Medium key in the MediumType record (which of course you need to set when you create a new MediumType). (I'm getting a bit dizzy here …)
 
If there are many MediumTypes and you would like to make pre-selection of MediumTypes based on a Medium, then use a global field as a filter device. This way you get a nice, short list of MediumTypes; if you make a selection, that key will be stored with the Item, and with that you know the associated Material, without having to store a key for it in the Item, too.
 
I hope I got all that right – I'm still not sure about the kind of relationship that Medium and MediumType have …
 
Anyways, here's a sample to show you what I mean, using a global as a selection tool; you see how selecting a MediumType ID create an indirect connection to Medium, and you can display the value, without having to store the Medium key itself. (But read the notes on the layout, pertaining to the pitfalls of conditional selection value lists.)
 
As for going back to square one: you haven't put in much functionality, so it may not be a bad idea. Send me a PM if you want some design and interface tips, and/or search this forum for best practices.
Art Supplies and Tools Database_eos.fmp12.zip

Wrap the existing statement into an If:
 
If ( not isEmpty ( Landline Trimmed ) ;  yourExistingStatement )
 
btw, why not GetAsNumber ( Landline Trimmed ) ?

Try this. I wasn't in the mood to write a script, so I went with my idea. You can continue using that field, or, if you need an indexed version, define a new field and use the logic to do a Replace Field Contents (which you may want to put in a script for further use).
SelfJoin_eos.fp7.zip

There are different syntaxes; I found that the one from Oracle works in FM (see screenshot). Put the string in single quotes.
ExecuteSQL ( "   SELECT '$' || n_transactionAmountGross,  t_transactionModel   FROM Transactions     WHERE  FamilyID_CustomerID = ?   "   ;    " : "   ;   ""     ;   FamilyID )