newEditCommand refuses to edit record

[Quartekoen]

This one's got me stumped.

In my database, I have a text field that I use as a flag. When a user requests the record (currently done via IWP), their name is set into the field to prevent other users from entering the same record at the same time. This has been working well for the last couple years. However, now I am trying to do the same thing via CWP.

Here is a snippet of the code I'm using. Please note that this page is called via AJAX, so I can't get feedback about things by just using echo. As such, I wrote and included a little WriteToLog page that can spit out any text I need to a text file.

include_once( "WriteToLog.php" );

$user = $_POST["user"];

$pass =  /* this is my little secret... */



/* Here I perform a compound find, which works beautifully */



$records = $result->getRecords();



if( count( $records ) == 0 )

	  exit;

$firstRecord = $records[0];

$firstRecordID = $firstRecord->getRecordId();





// Claim the first record for picking

$editRequest = $fm->newEditCommand("PHP_Order_Details", $firstRecordID);

$editRequest->setField("Picking_Completion_t", "picking-" . $user);

$editResult = $editRequest->execute();



if( FileMaker::isError( $editResult ) ) {

	  WriteToLog( "Error: " . $editResult->message . "(" . $editResult->code . ")" );

} else {

	  $editRecord = $editResult->getFirstRecord();

	  WriteToLog( "Completion: " . $editRecord->getField("Picking_Completion_t") . " - " . $editRecord->getField("ITEM"));

}



/* Then return the record data for me to display on my PHP page */

Here's where it starts getting weird... This works for me and me alone. ONLY me.

I often log into the CWP page and into FileMaker at the same time to watch the record and ensure the change is taking place correctly. Sweet. Then I log in as anybody else and do the exact same thing. Nothing.

My first thought was that this was somehow a permission issue. I reviewed all the permissions for the databases involved, the layouts used, and the fields need, and they all have sufficient access to all of them.

Then I realized that this probably ISN'T a permission issue

A ) The permissions involved all seem sufficient.

B ) While I'm logged in as myself, I have [Full Access] permissions. However, this still does not work even if I'm logged in as other users that have [Full Access].

Oh, and it gets weirder... See that little section in my code that gets the value of the now-edited record and writes it to my log? Well, the log says that the field did modify correctly! If I'm logged in as Bob and I try to modify the field, there is no change in FileMaker, but the Log records the ending value of the field as "picking-Bob".

I can't think of anything else to check.

The field is a flat text field (no calculation, default, lookups, etc...)

Users have been modifying this field via IWP for years.

All users have sufficient privileges to edit the field, record, layout, database...

All users are allowed to access the field, record, layout, db... though PHP.

The PHP page doesn't die as though it encountered an error. It happily completes and returns the rest of the record data that I request...

When I originally wrote this page, I hard coded my own credentials into it while I got it working. I have since obliterated all traces of these.

Also note that all users (including myself) are logged in via external authentication on our database host machine.

I would appreciate ANY ideas as to what might be going on here... Thank you.

UPDATE: It seems to be a problem with the field itself. Users are able to successfully update other fields with text, just not this flag field. Other fields can even be updated within the same editCommand, yet only I can actually get my name to appear in the flag field...

Edited May 17, 2012 by Quartekoen

[webko]

For testing I'd probably write a page that goes direct rather than with AJAX and see what happens.

After that, I'd recreate the table from scratch and try on that

[Quartekoen]

See, webko, this is why working in groups is the best way to go. Your simple suggestion lead me to the answer. Here's what is happening.

Because my users currently use IWP for some of their work, I can't guarantee that they're going to purposefully close their connection to the database cleanly. Sometimes computers crash. This means that if a record has a flag set, then nobody else will be able to get into that record if they crash. Luckily, it seems that filemaker calls the On File Close scripts on databases when it realizes a user is no longer connected. I have an On File Close script set up to clear out all flags for a user when they disconnect.

Because I'm using quick connections the FM Server from PHP, the page loads, flags are set, other stuff is done, and then the page disconnects from FM Server. This is triggering my On File Close script which immediately removes the flag I just set. I just have to prevent that script from firing and problem solved! Thanks!