Hello, I have a single .fp7 file that contains around 12,000 records.
I'd like to know if there is a way that I can split this file into two
separate ones. I'd like to be able to perform a find, then tell FM Pro
to take those records OUT of the current database and INTO a new (or
pre-existing) one. Kind of like a records transplant.

I thought about just duplicating the file, then opening each to delete
the opposite records, but it seems like there should be a better way
to do this.

Much thanks.

On 26/08/2010 18:35, Tim D. wrote:

I reckon that your own suggestion in para 2 is a pretty good, easy way
to achieve your goal There may be other ways I haven't thought of but
I'd be inclined to do that. It would take all of 2 minutes?

Yes, I think that's probably what I'll do. I was just hoping there
would be an easier way (e.g., "Export found records as new file"), but
I'll probably just plan on doing the plan I mentioned. Thanks for the
reply!

On 2010-08-26 10:55:08 -0700, "Tim D." <timothydavie (AT) gmail (DOT) com> said:

Well, if you'd bothered to look at the export options before posting to
UseNet (twice) you'd see that there *is* indeed an option to export as
a Filemaker file.

You'll get barenaked field defs in the export file, of course, with no
programming or any other objects from the old file. If that's what you
want.

Generally, unless you've got a specific purpose, such as delivering a
subset of data to a client for some reason, exporting into a separate
file just to separate two sets of data is poor idea. Better to tag one
set with a "type" field or other specification.

And for delivering data to clients, Excel format is generally better
understood and more useful to them. Also an export option. Ahem.
--
Lynn Allen
--
www.semiotics.com
Member FBA
FM 10 Certified Developer

Hi Lynn, thanks for the reply.

My reason for asking the question is that I've recently become
interested in using my database on my iPhone using FileMaker Go.
Trouble is the file is around 30 Gb, so transferring it back and forth
frequently would not be an option. My idea is to take just the piece
I'm working with, transfer that to the phone, use it, then transfer it
back to the computer, continue to use it, etc. At the end of the
period of time I'm working with those records, I'll just pull them
back into the "mother" database, and have everything in one place
again.

Any thoughts you have about how I could do this more efficiently would
be greatly appreciated.

I don't have resources to serve the file in order to use it online
from my phone.

Thanks.

Hi Lynn, thanks for the reply.

My reason for asking the question is that I've recently become
interested in using my database on my iPhone using FileMaker Go.
Trouble is the file is around 30 Gb, so transferring it back and forth
frequently would not be an option. My idea is to take just the piece
I'm working with, transfer that to the phone, use it, then transfer it
back to the computer, continue to use it, etc. At the end of the
period of time I'm working with those records, I'll just pull them
back into the "mother" database, and have everything in one place
again.

Any thoughts you have about how I could do this more efficiently would
be greatly appreciated.

I don't have resources to serve the file in order to use it online
from my phone.

Thanks.

Hi Lynn, thanks for the reply.

My reason for asking the question is that I've recently become
interested in using my database on my iPhone using FileMaker Go.
Trouble is the file is around 30 Gb, so transferring it back and forth
frequently would not be an option. My idea is to take just the piece
I'm working with, transfer that to the phone, use it, then transfer it
back to the computer, continue to use it, etc. At the end of the
period of time I'm working with those records, I'll just pull them
back into the "mother" database, and have everything in one place
again.

Any thoughts you have about how I could do this more efficiently would
be greatly appreciated.

I don't have resources to serve the file in order to use it online
from my phone.

Thanks.

In article
<6b53573d-f9f3-43f8-b35c-ca2584eecda0 (AT) o7g2000prg (DOT) googlegroups.com>,
"Tim D." <timothydavie (AT) gmail (DOT) com> wrote:

Well, there is an export function, and it does work on the currently
found set... You can also "Save a Copy As..." and select the "Clone"
option to create an empty database to import your records into.

Which is a bit (but not much) more work than first saving a compressed
copy, finding the records you want to remove, and deleting them.

On 2010-08-26 12:41:54 -0700, "Tim D." <timothydavie (AT) gmail (DOT) com> said:

In that case, I'd create a clone of the file, find the small set of
records you want on the phone, and import it into the clone. Put the
clone on the phone.

You can script this process as long as you name the clone the same
thing every time you do it.

You could also try creating a compressed copy of the file. This
sometimes removes enough extra space, depending on the use of the file,
to significantly reduce the size of the file. You might get the whole
thing on the phone.

Remember, this kind of sneaker-net synchronization only works really
well with one user. The moment you get two....yeesh. Lots more work.
Better to host it.
--
Lynn Allen
--
www.semiotics.com
Member FBA
FM 10 Certified Developer

Hi Lynn, thanks for the reply.

My reason for asking the question is that I've recently become
interested in using my database on my iPhone using FileMaker Go.
Trouble is the file is around 30 Gb, so transferring it back and forth
frequently would not be an option. My idea is to take just the piece
I'm working with, transfer that to the phone, use it, then transfer it
back to the computer, continue to use it, etc. At the end of the
period of time I'm working with those records, I'll just pull them
back into the "mother" database, and have everything in one place
again.

Any thoughts you have about how I could do this more efficiently would
be greatly appreciated.

I don't have resources to serve the file in order to use it online
from my phone.

Thanks.