Jump to content
matto1376

How to copy a record to a remote filemaker database - noob here sorry!!

Recommended Posts

matto1376

Hi Guys,

 

Just wondering if anyone can point me in the right direction please.

I have a Filemaker 7 Database that is populated by text records, it is pretty straight forward and works fine. The scenario is, at the end of the month these text records are collated and printed in a magazine.

 

What I would like to do is have a duplicate Filemaker database in structure hosted remotely, and have an 'Export' or 'Send' button on my original database.

When I hit that button the record I am working on gets copied to the duplicate database which is hosted elsewhere.

 

Is this possible??

 

Hope it makes sense!!

 

Thanks in adavce.

Share this post


Link to post
Share on other sites
AHunter3

Yes, it's possible.

 

Why do you want your data to be migrated to a separate database? Generally speaking, it's something that a lot of newbies think they should do, but that experienced developers would not do in that same situation.

 

Anyway, there are several different ways of doing it.

 

• If your database (your local one) is always online and always at the same IP address, and that IP address is directly accessible from the other database (that is, if someone at that location can go File menu ——> Open Remote ——> Favorite Hosts {add your IP as a Favorite Host}: and see your database) then you can add your database as a file reference in the other database and then a layout native to your table can be added to the remote database's layouts; a flag field created in your database to indicated that a given record has already been imported; and then in the remote database a script is created that does a Find for non-flagged records in your database (on that new layout) and then a Go to Layout to go to one of that database's native layouts followed by an Import Records to import data from your database; finally, a Go to Layout to to back to the new layout that has your data on it, a Replace Field Contents on the found set to mark those as having now been imported, and you're done.

 

• Or you could push rather than pull: create an external reference to the remote database there within your own db, create a relationship between your data table and the appropriate (target) data table in the remote database, allowing creation of records on the remote side via that relationship, and then using Set Field to set all the various data fields to the values that are present in the corresponding record in your own db table.

 

• Or you could just export from your database to an export file format (Merge file, or Excel with headers, or native FileMaker) to a folder on your computer, email or FTP it to the other remote computer, and someone at the remote location (or you, via remote control) imports from that file when it arrives.

Share this post


Link to post
Share on other sites
matto1376

Thanks AHunter - that is just the reply I was hoping for....!! Quick reply too...

 

My preferred option was your second scenario - pushing data to the remote.

 

So far I had no worries with this bit -

create an external reference to the remote database there within your own db, create a relationship between your data table and the appropriate (target) data table in the remote database, allowing creation of records on the remote side via that relationship
(For those of you reading this later on - in FMP go to File > Manage > Database and hit the 'Relationships' tab, play around and it should be simple to set this up)

 

The next step is this bit:

and then using Set Field to set all the various data fields to the values that are present in the corresponding record in your own db table.
I will have a crack at it myself, but I'm not quite sure what to do there, or how it is meant to work. Pointing me in the right direction though I think...

 

Should 'set field' work so that every time I create a new record in DB1, it pushes the changes to DB2? Or do I set up a button with a script that triggers the push? I'm guessing this is functionality I can define?

 

Thanks again, please excuse the ignorance.

Matt

Share this post


Link to post
Share on other sites
AHunter3

Let's go back to why you want to do this in the first place?

 

I'm not saying there aren't legitimate reasons, but you did indicate that you are entry level. If it's not too invasive a question, I want to know your thinking behind the idea that this data should exist in two different places.

Share this post


Link to post
Share on other sites
matto1376

Yep totally cool...I only arrived at this line of thinking from what I could gather so far from general reading, I'm not set on it and definitely open to alternatives. It's the end not the means....

 

The scenario is this.

I am developing a site for a magazine. As a magazine, they work exclusively with Macs (my background is totally PC based).

They currently have their journo's enter articles directly into FMP, then the people who lay out the magazine grab the flat text from there.

 

Their current website is PHP / MySQL, so if they want to publish an article on the web, they copy and paste the text into a web based front end editor. which is what they want to get away from. It doubles up the process and is pretty clunky, not fun.

 

So the idea would be to have a Print Production db (already eixsting) and a Web Production db (hosted off site). If they want to publish an article to the web they hit a button in FMP, and it is transferred to the Web Production Db. (The magazine editor didn't want them in the same location - which is fine)

 

I should add at this stage I have developed the web side of things using FMP / PHP - no major dramas there, and can pull data from the existing FMP db.

 

Thanks for your help on this Hunter, interested to hear what you have to say.

I hope I have explained that well enough.

Matt

Share this post


Link to post
Share on other sites
Jack Rodgers

What if you could just produce the html page directly from your record?

 

I have created databases that auto created the html pages using this idea:

 

Browse to the html page you want to replicate. Use the show code selection in the browser and capture the entire html page as text.

 

Paste the html text into a Filemaker field. Use that as a template to copy to another field.

 

Locate various portions of the page that you can replace with something like "{HTML notes}" and "{HTML company name}" and so on.

 

Now you can do a substitute using Filemaker script to substitue your desired information for the location in the html text you copied to the third field.

 

Save that field as text and you have your new html page.

Share this post


Link to post
Share on other sites
AHunter3

a) I would do it all in one database. Probably I would do both of those "production" data sets as one TABLE in one database, with a status field of some sort to indicate that "this one is ready to be worked on by the web production folks". Any reason why not? At worst, you might have some data that just isn't relevant to web but needed for production and vice versa; if so you use different layouts.

 

b) If they currently use a MySQL web site, you can create external file references to the MySQL tables just as you did to link the two FileMaker databases, and then wtihin FileMaker you can treat the MySQL tables just like native FileMaker tables. (Well, except for defining new data fields, you'd still do that in SQL-land). That would give you the flexibility of having "everything in one FileMaker environment" yet not require rebuilding the web front end. Not sure that's a concern for you here.

 

 

if you still want to transfer data between two database files as described though...

 

a) In your relationship between the two tables make sure the "allow creation via this relationship" checkbox is checked in the definition of the relationship itself.

 

b) I do not know what your various data fields are, or how many of them there are. For our example let's assume you have Name, Description, Date Created, Author, Article Text, and Comments. And that you have an identically named set of fields in the external database, into which you would want to transfer all that data.

 

Set Field [External Database Table::Name; LocalTable::Name]

Set Field [External Database Table::Description; LocalTable::Description]

Set Field [External Database Table::Date Created; LocalTable::Date Created]

Set Field [External Database Table::Author; LocalTable::Author]

Set Field [External Database Table::Article Text; LocalTable::Article Text]

Set Field [External Database Table::Comments; LocalTable::Comments]

 

If you have zillions of fields, you might wish to create a reciprocal relationship on the relationship diagram of the target database file, and then change the field definitions of those fields to have an auto-enter LOOKUP value that looks up from your (local) database's table. Then you don't have to do all those Set Field script steps, they just automatically fill in.

 

Note that I have not discussed exactly how the two tables are to be related. Your local table should have an auto-enter serial number, one that is guaranteed unique and does not change. If it doesn't, you should create one and retroactively fill in serial values for your existing records. In the external file's table you should create a foreign serial field which has no purpose other than indicating which serial number the SOURCE DATA in your local file/table it came over from. Set those two fields to equal in the relationship definition.

Share this post


Link to post
Share on other sites
matto1376

Hi Jack,

 

Thanks for your replies guys, I was almost going to bed, it's nearly 3am in Australia but I'm on a mission now!

 

To answer you as well Jack, I guess what I am trying for is a traditional CMS site but using FMP instead of MySQL (bringing you crazy Mac guys to the mainstream!!!), and keeping FMP inherent to the workflow - as that is what the journo's are most comfortable with (read - no way I could talk them into giving up FMP!!). So if you can't beat them join them. That's when I bought my MacBook Pro and registered on this site.

 

So FMP Server is the container for all dynamic data....actual html would be edited using normal means...(as the html and css styling would be constantly changing also) with dynamic data being manipulated using FMP instead of a web based front end or phpMyAdmin, etc.

 

The editor of the magazine insisted on a separate location for the web data. I guess if you have ever been at a magazine around deadline time, you know they go absolutely nutso if work gets interupted, so the integrity of that system is paramount. So I was cool with that - that's the way it had to be. That way all web traffic hits a totally physically separate server.

 

So, that leads me to continue on the second idea of transferring data.

 

With this part:

 

Note that I have not discussed exactly how the two tables are to be related. Your local table should have an auto-enter serial number, one that is guaranteed unique and does not change. If it doesn't, you should create one and retroactively fill in serial values for your existing records. In the external file's table you should create a foreign serial field which has no purpose other than indicating which serial number the SOURCE DATA in your local file/table it came over from. Set those two fields to equal in the relationship definition.
That is all cool, well explained.

 

If I go down this implementation path:

 

Set Field [External Database Table::Name; LocalTable::Name]

Set Field [External Database Table::Description; LocalTable::Description]

Set Field [External Database Table::Date Created; LocalTable::Date Created]

Set Field [External Database Table::Author; LocalTable::Author]

Set Field [External Database Table::Article Text; LocalTable::Article Text]

Set Field [External Database Table::Comments; LocalTable::Comments]

I am guessing I create a script with this content, then have a button to trigger this script?

 

And the alternative implementation:

 

you might wish to create a reciprocal relationship on the relationship diagram of the target database file, and then change the field definitions of those fields to have an auto-enter LOOKUP value that looks up from your (local) database's table

This makes sense - it's 3am now so I'm gonna turn in, I will give these a go tomorrow and post back how it turns out.

 

I hope I am explaining it better as I go along!! Thanks so much for your input!!

Hopefully someone else will get a bit out of this when they switch to Mac....

Share this post


Link to post
Share on other sites
matto1376

Hi Hunter....

 

So we got as far as setting up the recipricol relationship, and both are ticked to allow record creation and the fields are set to auto look up like you stated.

 

What doesn't seem to be working is the creation of the new record on the remote db.

 

What is supposed to be the trigger to have a new record generate on the remote db??

 

If you create a new record on the local db, and then manually create a new record on the remote db, the auto look up will work. But that step of actually getting the new remote record generated is the problem at the moment.....

 

 

Am I missing something in config??

Share this post


Link to post
Share on other sites
AHunter3
Hi Hunter....

... {snip}

that step of actually getting the new remote record generated is the problem at the moment.....

 

 

Am I missing something in config??

 

Probably this:

 

a) In your relationship between the two tables make sure the "allow creation via this relationship" checkbox is checked in the definition of the relationship itself.

 

When you do a Set Field [anyRelationship::anyEditableField]

 

...and there is not already a record related to the existing record, one will spring into existence to receive the value in the Set Field script step. If and only if "allow creation" is checked.

Share this post


Link to post
Share on other sites
This thread is quite old. Please start a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.




×
×
  • Create New...

Important Information

Terms of Use