AnsweredAssumed Answered

Script breaking only on Macs

Question asked by millerb on Sep 3, 2014
Latest reply on Sep 8, 2014 by millerb

I'm trying to help a nonprofit on the other side of the country with a FM13 database. A script I created always works very, very consistently on my PC, but is sometimes breaking, apparently in a couple different ways, when folks are using Macs. Unfortunately I don't have access to FM Pro on a Mac, so I can't figure out how to debug this. I see nothing obviously wrong with the script. I'm not using any commands incompatible with Macs. One person who had trouble with the script had full access privileges, so that doesn't seem to be the issue.


The database has a contacts module that includes both organizations and individuals. Since these need to be treated as different entities in this solution, there are two separate tables, ORGANIZATIONS and PERSONS. In order to allow searching and viewing of lists of both types of contacts, there is a ContactsJoin table. ContactsJoin has a field for its own auto-created ID, a field for _OrgID (foreign key to the ORGANIZATIONS table) and a field for _PersonID (foreign key to the PERSONS table). All the IDs are generated using the "UniqueID" function. Validation for both _OrgID and _PersonID fields is as follows:

Validate Always

Unique value

Validated by calculation:

for _PersonID: "IsEmpty(_OrgID)"

for _OrgID: "IsEmpty(_PersonID)"


This calculation validation just ensures that no join record gets accidentally created that links to both a person and an organization. This shouldn't ever happen anyway, but it did once when I had another faulty script, so I set it up in an abundance of caution. That's not the problem, I don't think.


When someone creates a new contact, say an Organization, a new record is created in ORGANIZATIONS. After they finish filling in data, they have to hit a "Save" button. This triggers the troublesome script. Here it is:

  • Commit Records/Requests
  • Set Variable [$OrgID; Value: ORGANIZATIONS::_ID]
  • Set Variable [$Name; Value: ORGANIZATIONS::OrgName]
  • Freeze Window
  • Go to Layout ["@ContactsJoin" (ContactsJoin)]
  • New Record/Request
  • Set Field [ContactsJoin::_OrgID; $OrgID]
  • Set Field [ContactsJoin::Initial;Upper (Case (not IsEmpty ($Name); Left ( $Name; 1 ); " -- " ) )
  • Commit Records/Requests
  • Go to Layout ["ContactList" (ContactsJoin)]


The "Set Field" for ContactsJoin::Initial just assigns the first letter of the Organization name to an initial field for sorting of Organizations and Persons together.


One person told me they were taken to @ContactsJoin (which is not intended for user viewing) and received a message that _OrgID must be a unique value. However, it should have already been unique, having just been created as a new record in ORGANIZATIONS. This person had full access privileges.


Another person said they were taken to @ContactsJoin and received the message: "Commit records/request has been canceled. Do you wish to continue with this script?" Then the database froze and they had to force quit. When they reentered, the records had been created (in both ORGANIZATIONS and ContactJoin), but the ContactsJoin::Initial value had not been set.


Anyone see what could be causing this problem? It appears that in one case $OrgID may not have set to a new value correctly and in another case $Name may not have set correctly, but I can't imagine why, and why only on Macs? Any leads? I could try to upload a copy, but the solution is so big it would take me quite a while to pare it down to the relevant parts. I will if necessary.