Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

This topic is 8254 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

Hello Everyone,

This one problem has been driving me absolutely crazy, I'm hoping someone can help me. smile.gif

I have two databases that are identical. They are both called "Main Database". One of them is running on Filemaker Server in our office and is shared. The other sits on my Notebook computer for me to take home at the end of the day. I am trying to write a script to import the new / changed records from the database on the server to the one on my notebook.

On my Notebook version of "Main Database" I wrote the following script. The external script it mentions I have laid out further down the page.

Copy [select, "Last Sync"]

Perform Script [subscripts, External: "Main Database.fp5(*)"]

Import Records [Restore, No Dialogue, "Main Database.fp5(*)"]

Set Field ["Last Sync", "Today"]

Exit Script

In the Database on the server I wrote this script: (This is the external script that the mobile one refers too)

Enter Find Mode

Insert Text ["Last Modified", ">="]

(select entire contents)

Paste ["Last Modified"]

Perform Find

The problem is when I try to run the script, it falls into a loop where it endlessly pastes the contents of "Last Sync" into "Last Modified" on the portable database. It seems to take it's instructions from the script on the server but perfoms them in the portable database. I've also tried just writing a scipt that imported the records without the find and I get the message the file is locked or in use.

I made extra sure that when I specify the database in the external script dialogue box, I specify the correct one on the server.

I just can't figure this one out! frown.gif If anyone has any ideas I would be forever gratefull.

Cheers,

Christian Knudsen

Toronto, Canada

Posted

Perform a search in the Forums for "synchronisation" and other similar terms to view the general consensus.

Executive Summary: don't. The problem is working out the "rules" for synching the records: to be workable they have to be really simple, but when they are really simple they aren't very useful.

Example: you spend time updating a record at home, and another user updates the same record on the server. Which is the version to keep? What if you delete the record at home but another person updates it?

Solution: one database only. Connect into it remotely. OR ensure that "your" records cannot be modified by any other user (which neatly side-steps the synching problem into a simple issue of importing).

Posted

When you have a local file with the same name as a served file, you're almost guaranteed to have problems.

So 1. rename the local file (99% sure that's your problem).

2. Put Pause steps into your scripts so you can see if things are happening as you expect.

3. Set error capture on and see if your find is working as expected -- e.g. what if no records are found?

Posted

Thanks for your help! smile.gif

I actually just need to be able to view the data at home and create new records. I don't plan to ever modify records at home.

I suspected that the problem might be in the fact that both files have the same name. I was worried about that, because I was hoping to use this same technique with the related databases on the server. If I change the name, I think all my relationships, portals and stuff are going to stop working. This doesn't happen with Filemaker Developer right? Maybe it's time for an upgrade.

I'm going to try your advice. Wish me luck and thanks a million for both of your replies! smile.gif

Cheers,

Christian Knudsen

This topic is 8254 days old. Please don't post here. Open a new topic instead.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.