keywords

The second Set Field step in your script (after the Else If) will not work as the field to be set is not specified, only the result to be posted. On the other hand, see comments above if the target field you intend to be set is in fact a calc field.

Re: "I can solve this by creating an opener file with everyone's user name and password, but I'd rather not have to do this with every new end user!" Every new end user will have to have credentials set up—or at least assigned, if you use shared credentials such as Staff, or Accounts Staff—for the target file anyway, so I'm not sure I see the problem. The opener file should have the same set of accounts as the target file, and should be where users actually log in—your log in script will then carry over the credentials they enter, log them into the target file, and lastly close the opener file.

Re: "for some reason the "Allow editing of of value list" option was (and still is) dimmed out on the data inspector." This is always dimmed out if the value list is based on contents of a field.

Fair enough!

I've only just seen this post from a week or so back, but here is a thought. "Comment" said: "with no date being given, it will use the first date on its calendar". I am not so sure about that; it could use the current date as the default date—it would be more logical. Here is why I think this may be so. The behaviour you report looks suspiciously like behaviour I have seen on computers in the past when their internal battery died. When a computer is switch off it has an internal battery to delivery just enough power to maintain some internal storage of things like its internal clock—that is why you don't have to reset those things every time you restart your computer. When this battery dies the clock stops; an indicator that this has happened is that the date on the internal calendar has reverted to 01/01/0001. You can reset the date and carry on as normal, but when the computer is shut down … you get the idea. So, Harry, IF the computer on which you are seeing this change of behaviour is one which is shut down regularly—or perhaps was shut down and restarted just before this started to play up—the cause may simply be that it needs new internal battery.

Re "be able to add a value on ad hoc basis". If the list uses custom values you can check the Allow editing of value list option in the data inspector.

I've only just read your post, but since no one has replied in 13 days perhaps a few thoughts even at this late stage may assist your thinking. 1. In the first part you say the the auditions db is flat—I assume that means it has just one table. Then in part three you ask about "adding a database with another 16 tables". My first thought was that you could simply add the auditions table to the larger db, but this bit confused me somewhat. 2. Again, I was a little confused by your statement: "the ID is their school ID". I trust this simply means the ID that is used to identify them within the overall school db. You DO have a unique, reliable pupil ID field, right? 3. If you do simply add the auditions table, then relating it to the pupils table via the pupil ID is the obvious way. However, this means that some of the people in the pupils table will not actually be pupils, but only potential pupils. You may thus need to consider adding a status field (candidate, pupil, graduate, etc), maybe changing the name of the pupils table to something more generic. There are a few other possible issues to consider, but that will do for a start.

Two points: 1. I think the key is to make sure you have the data in an acceptable date format BEFORE you switch the field type. For example, if the text data in the field is 27/02/14 FM will easily convert it to that same date, but if it is 270214, FM will leave it as is. 2. A variation on the formula given by hbrendel is to make use of the Self function in place of the field name in your data replacement formula, and also use "/" as per your original post, instead of "–". 3. The formula will only deliver a correct result if the text date is six digits (ie. 270214). Result will be wrong for any dates that don't have leading zeros on days and months (eg. 1314 instead of 010314). OK, so it's three points!

"I should find all records where the Selections field has both the Options1 and Options2 checkboxes checked" You could try using the exact match operator (==) in your Find and see if that makes a difference.

Why don't you try just stretching the fields using the field toggle handles on the inspector. That way, if you do happen to have Bartholomew whatsisname and the field is too small to display it, you can stretch the window and thus the field so that it can be viewed. Just a thought.