Push Failure Error 504

[Darren Burgess]

I am getting an error on push to the server 

 

"The attempt to push data to the server has failed (The message received from the server was 504)"

 

 

Error 504 is:   Value in field is not unique as required in validation entry options

 

The only field in the server data base that requires uniqueness is my ID.  This is an auto enter UUID.

 

There is also the ES_Record_UUID field, but this seems to not be set to require uniqueness by default.

[Darren Burgess]

I resolved this error by removing the uniqueness validation from my primary key.  Although I am not so sure that is a good idea.  Any thoughts?

[timdietrich]

Darren --

 

I just tried replicating this, and I'm not getting the 504 error.

 

Here's what I did...

• In the EasySync demo database, in both the hosted and mobile DBs, I set the "Survey_ID" field (which was already configured to auto-enter w/ "Get ( UUID )") so that the "Require Unique Value" validation option was checked.

• I then updated a record in the mobile DB (one that already existed in the hosted DB) and synced. That worked.

• I then added a new record in the mobile DC, and synced. That worked as well.

 

Is there something else about that field (or perhaps another field) that might have caused the 504 error to be thrown? Perhaps a PK in a child record?

 

-- Tim

[RyanESmith7]

I am getting this error also on my first sync. I haven't fully looked into it, but I'm going to assume it is trying pull from the server to the mobile. 

[mkos]

I am also getting this error.

I have an ID field in my table which is configured to auto-enter with Get ( UUID ) and which had "Require Unique Value" turned on. When I modify a field in a record in the mobile file and try to sync, I get the 504 error during the push-to-server part.

When I turn the unique value requirement off, the sync goes through without errors, but a duplicate record is created in the hosted file. My ID field and the ES_Record_UUID field both have duplicated values in this new record.

I am using EasySync v1.2. I double-checked that the relationship from the EasySync table to my table is set according to the documentation on both the hosted and the mobile files: EasySync_Payload_Details::ES_Child_Record_UUID = ES_MyTable::ES_Record_UUID.

[timdietrich]

It seems like we're seeing this error more and more.

 

I'm going to dig into it this weekend, and see if I can't get to the bottom of it...

 

Thanks guys!

 

-- Tim

[timdietrich]

Hi everyone.

 

I spent some time over the weekend trying to replicate the dreaded "504" error that has been reported several time now, and I'm still not seeing it. In fact, if you pull the new version (1.3) of EasySync, you'll see that the demo database now has the "Unique value" option set on the "Survey_ID" primary key field in the Surveys table. It seems to sync without the 504 error ever being thrown.

 

Without being able to replicate the problem, diagnosing this is extremely difficult. My hunch is that, for some reason, FileMaker isn't "seeing" the existing record through the relationship between the EasySync_Payload_Details table occurrence and the "ES_" table that it is referencing. As a result, it tries to create a new record, which fails due to the "Unique" criteria of the PK field.

 

For those of you who are running into this, I'm wondering if you can confirm that the field type for the ES_Record_UUID field is set to Text in both the mobile and hosted databases. A difference in field types might explain why the relationship is failing. It's a long shot, but it's all I've come up with so far.

 

Thanks for your patience with this one. It's elusive, and as you all know, the most difficult type of bug to find and squash.

 

-- Tim

[RyanESmith7]

Hey Tim,

I've got a scenario where I can recreate it over and over. I've played with until I'm blue in the face, so if you'd like to take a look at it, let me know and I'll email you the file.

Thanks,

Ryan

[timdietrich]

Ryan --

 

If you don't mind zipping it up and sending it to me, I'd appreciate it.

 

Thanks for the offer.

 

-- Tim

[doughogg]

Hi Tim,

 

I just checked. All three ES_Record_UUID fields are set to Text in both the mobile and hosted databases.

 

:-)

 

Doug

 

 

For those of you who are running into this, I'm wondering if you can confirm that the field type for the ES_Record_UUID field is set to Text in both the mobile and hosted databases. A difference in field types might explain why the relationship is failing. It's a long shot, but it's all I've come up with so far.

 

[timdietrich]

Thanks, Doug.

 

There goes that theory...

 

-- Tim

[RyanESmith7]

Tim, I recreated my Mobile file and now I'm no longer getting the 504 error (instead I'm getting a 106 error). I've moved that to a different topic. 

Thanks,

Ryan

[timdietrich]

Ryan --

 

Interesting.

 

Any idea as to what you changed this time around?

 

Also, I'm curious to see if, when you resolve the 106 error, the 504 error manifests again.

 

Please keep us posted.

 

-- Tim

[RyanESmith7]

I think what was happening before is I was copying my hosted solution, deleting all the data, and then attempting to do a sync. I saw in another thread your recommendations for fixing that, but before I had a chance to try that, I'm just trying to simplify it by doing a sync with an exact replica.

[doughogg]

Hi Tim,

 

Hopefully a clue to this error:

 

I only get the 504 error on pushes when I have edited an existing record.

 

:-)

 

Doug

[mkos]

I was getting this error but am not any longer. I discovered that I didn't copy over the contents of the EasySync_Payloads layout on the hosted file correctly. The 504 error hasn't shown up ever since I fixed that layout.

[MHOOLE]

Hi everyone

 

I was getting the 504 on push and pull.  The change that I made, that seems to have resolved the error is as follows:

 

For one of the tables that I was syncing, I did not have the unique_id field on the layout.  I added the unique_id field to both the mobile and hosted fmp databases.  Synced and that seems to have resolved the 504s for both push and pull.

 

Hope that helps.

 

edit... FYI... I think this also might have to do with records persisting in the EasySync table after I "reset" my database.  The reset was not deleting all the records from the EasySync table.  I added a bit of code to my reset button to ensure that all the records in the EasySync table were also deleted.

[doughogg]

Hi MHOOLE,

 

Have your tried syncing after editing a previously synced mobile record. That is where I get a 504 error on pushing.

 

:-)

 

Doug

[Jodin]

I was getting this error but am not any longer. I discovered that I didn't copy over the contents of the EasySync_Payloads layout on the hosted file correctly. The 504 error hasn't shown up ever since I fixed that layout.

 

 

This is exactly my story.   I had the client version of the payloads screen on the server version. I cleared that layout, copied over the proper one from the example file, and the 504 error went away.

[Jodin]

Make sure your Payloads screen on the server is not in table view, that seemed to give the clients the 504 error also.

 

[juli51]

Hi all, Try avoid EasySync_Payloads Layout from being in table view. 

 

[Agentshevy]

Hi all.. Just read through the whole posts, I have tried several of the fixes proffered, haven't been successful yet..  

In my case, first syncing works well, no hassle... And then I tried importing new records into the mobile client.. After that, any syncing attempt brings up the 504 error.. 

My DB  has fields with unique validation like phone, product names, social security number....  Can those really be the cause? Or is it as a result of the import I did? 

[Agentshevy]

Looks like I figured it out... While importing new records, I should have ticked the box that says Perform lookups.....  That was the problem on my case... Thanks to you all for your contributions.. They were very helpful as always 

[bertmaker]

On 17-2-2015 20:38:17, Jodin said:

 

 

This is exactly my story.   I had the client version of the payloads screen on the server version. I cleared that layout, copied over the proper one from the example file, and the 504 error went away.

Hi Jodin,

I'm somewhat puzzled by what you write. I don't see any difference in the payloads screens between the server and the client although I looked directly at the examples provided by Mr Dietrich. Would you mind explaining what the differences are between the 'client version' and the 'server version' of the payloads screen?

 

Thanks in advance, as you might have guessed I'm in the middle of a re-occurring 504. wiping and resettings helps for some time but it keeps getting back on me.

 

regards,

 

Bert

[bertmaker]

I might have resolved my 504 error by removing some left-over 'delete portal row' script steps and replacing them by calling the 'easysync delete record' script as I should have done in the first place.

 

Hope this helps someone, Bert

[bertmaker]

One more thing;

I noticed some of my records didn't have ES_Record_UUID and ES_UTC_Time fields filled in. Dunno what caused that but I guess it was a faulty import. It could explain the 504 as empty fields aren't exactly 'unique'. I filled in all missing ES_Record_UUID values using :

if ( IsEmpty ( ES_Record_UUID ) ; Get ( UUID ) ; ES_Record_UUID )  in the calculation of 'replace field contents'

 

Happy Holidays! Bert