dbTalk Databases Forums  

"Saving" data

comp.databases.filemaker comp.databases.filemaker


Discuss "Saving" data in the comp.databases.filemaker forum.



Reply
 
Thread Tools Display Modes
  #1  
Old   
Lee
 
Posts: n/a

Default "Saving" data - 03-16-2010 , 05:40 PM






I have one file with five years of data. How do I create a new file
with only data for one of the years?

Reply With Quote
  #2  
Old   
David Empson
 
Posts: n/a

Default Re: "Saving" data - 03-16-2010 , 07:04 PM






Lee <leehunt1 (AT) cox (DOT) net> wrote:

Quote:
I have one file with five years of data. How do I create a new file
with only data for one of the years?
One method is to save a copy of the database (with all records), then
open that copy, find all the records you don't want and delete them. The
database file can then be reduced in size by saving another compressed
copy.

For a simple database with a single table, you could find the records
you want, export them to a temporary file, save a clone (empty) of the
current database, open the clone, and import the records from the
temporary file. This is harder for a multi-table database as you would
have to export/import every table.

--
David Empson
dempson (AT) actrix (DOT) gen.nz

Reply With Quote
  #3  
Old   
Your Name
 
Posts: n/a

Default Re: "Saving" data - 03-16-2010 , 11:29 PM



"David Empson" <dempson (AT) actrix (DOT) gen.nz> wrote

Quote:
Lee <leehunt1 (AT) cox (DOT) net> wrote:

I have one file with five years of data. How do I create a new file
with only data for one of the years?

One method is to save a copy of the database (with all records), then
open that copy, find all the records you don't want and delete them. The
database file can then be reduced in size by saving another compressed
copy.

For a simple database with a single table, you could find the records
you want, export them to a temporary file, save a clone (empty) of the
current database, open the clone, and import the records from the
temporary file. This is harder for a multi-table database as you would
have to export/import every table.
You could also just Find and export the record's, and then delete them from
the database ... leaving the export file as the historical record (it would
take up less space and you could re-import them in the rare event that you
actually need them again).

One problem with exporting though is that it doesn't work for Container
field data.

Helpful Harry )

Reply With Quote
  #4  
Old   
105
 
Posts: n/a

Default Re: "Saving" data - 03-22-2010 , 04:25 PM



Quote:
One problem with exporting though is that it doesn't work for Container
field data.

In what way does it not work? Were you thinking that as exports will
probably end up in a different location node in the file hierarchy, that
data inserted into container fields as references, will lose the links?
Which does not happen because of the location of the FM file, only if
the referenced images/files themselves are moved. Or something else?

Doe this need to be qualified with some historical version?

Reply With Quote
  #5  
Old   
Your Name
 
Posts: n/a

Default Re: "Saving" data - 03-22-2010 , 07:13 PM



In article <4ba7ee46$0$8825$c3e8da3 (AT) news (DOT) astraweb.com>, 105
<cortical (AT) internode (DOT) on.net> wrote:
Quote:
One problem with exporting though is that it doesn't work for Container
field data.

In what way does it not work? Were you thinking that as exports will
probably end up in a different location node in the file hierarchy, that
data inserted into container fields as references, will lose the links?
Which does not happen because of the location of the FM file, only if
the referenced images/files themselves are moved. Or something else?

Doe this need to be qualified with some historical version?
Stored graphics / sounds / etc. are not exported since obviously the
export file formats (Text, Merge, Excel, etc.) can't store them.

I'm not sure about linked files, presumably the link gets exported as
normal text, but it may not be of much use depending on whether it's
linking the full file path or not, and whether or not the data is imported
on the same computer.


If you need to transfer data between two FileMaker databases, then it's
better to Import directly from the other databse, rather than export and
then import.


Helpful Harry )

Reply With Quote
  #6  
Old   
105
 
Posts: n/a

Default Re: "Saving" data - 03-23-2010 , 05:06 PM



Your Name wrote:
Quote:
In article <4ba7ee46$0$8825$c3e8da3 (AT) news (DOT) astraweb.com>, 105
cortical (AT) internode (DOT) on.net> wrote:
One problem with exporting though is that it doesn't work for Container
field data.
In what way does it not work? Were you thinking that as exports will
probably end up in a different location node in the file hierarchy, that
data inserted into container fields as references, will lose the links?
Which does not happen because of the location of the FM file, only if
the referenced images/files themselves are moved. Or something else?

Doe this need to be qualified with some historical version?

Stored graphics / sounds / etc. are not exported since obviously the
export file formats (Text, Merge, Excel, etc.) can't store them.

I'm not sure about linked files, presumably the link gets exported as
normal text, but it may not be of much use depending on whether it's
linking the full file path or not, and whether or not the data is imported
on the same computer.


If you need to transfer data between two FileMaker databases, then it's
better to Import directly from the other databse, rather than export and
then import.


Helpful Harry )

perhaps the point being missed, is that the op wants to isolate a record
subset. So it is not an issue of excel... Exporting as a FileMaker
file does export Stored graphics / sounds / etc.

Reply With Quote
  #7  
Old   
David Empson
 
Posts: n/a

Default Re: "Saving" data - 03-24-2010 , 12:33 AM



Your Name <your.name (AT) isp (DOT) com> wrote:

Quote:
"105" <cortical (AT) internode (DOT) on.net> wrote in message
news:4ba94966$0$8836$c3e8da3 (AT) news (DOT) astraweb.com...
Your Name wrote:
In article <4ba7ee46$0$8825$c3e8da3 (AT) news (DOT) astraweb.com>, 105
cortical (AT) internode (DOT) on.net> wrote:
One problem with exporting though is that it doesn't work for
Container
field data.
In what way does it not work? Were you thinking that as exports will
probably end up in a different location node in the file hierarchy,
that
data inserted into container fields as references, will lose the links?
Which does not happen because of the location of the FM file, only if
the referenced images/files themselves are moved. Or something else?

Doe this need to be qualified with some historical version?

Stored graphics / sounds / etc. are not exported since obviously the
export file formats (Text, Merge, Excel, etc.) can't store them.

I'm not sure about linked files, presumably the link gets exported as
normal text, but it may not be of much use depending on whether it's
linking the full file path or not, and whether or not the data is
imported
on the same computer.

If you need to transfer data between two FileMaker databases, then it's
better to Import directly from the other databse, rather than export and
then import.

perhaps the point being missed, is that the op wants to isolate a record
subset. So it is not an issue of excel... Exporting as a FileMaker
file does export Stored graphics / sounds / etc.

Unless it's something added to the newer versions (and I haven't looked in
FileMaker 9), you can't "export" records as a FileMaker file.
FileMaker Pro 7 and later can export as a FileMaker Pro database. It
produces a simple database with a single table containing the data from
the exported table.

For that matter, so can FileMaker Pro 6. (Isn't that the version you are
running?)

--
David Empson
dempson (AT) actrix (DOT) gen.nz

Reply With Quote
  #8  
Old   
Your Name
 
Posts: n/a

Default Re: "Saving" data - 03-24-2010 , 12:41 AM



"105" <cortical (AT) internode (DOT) on.net> wrote

Quote:
Your Name wrote:
In article <4ba7ee46$0$8825$c3e8da3 (AT) news (DOT) astraweb.com>, 105
cortical (AT) internode (DOT) on.net> wrote:
One problem with exporting though is that it doesn't work for
Container
field data.
In what way does it not work? Were you thinking that as exports will
probably end up in a different location node in the file hierarchy,
that
data inserted into container fields as references, will lose the links?
Which does not happen because of the location of the FM file, only if
the referenced images/files themselves are moved. Or something else?

Doe this need to be qualified with some historical version?

Stored graphics / sounds / etc. are not exported since obviously the
export file formats (Text, Merge, Excel, etc.) can't store them.

I'm not sure about linked files, presumably the link gets exported as
normal text, but it may not be of much use depending on whether it's
linking the full file path or not, and whether or not the data is
imported
on the same computer.

If you need to transfer data between two FileMaker databases, then it's
better to Import directly from the other databse, rather than export and
then import.

perhaps the point being missed, is that the op wants to isolate a record
subset. So it is not an issue of excel... Exporting as a FileMaker
file does export Stored graphics / sounds / etc.
Unless it's something added to the newer versions (and I haven't looked in
FileMaker 9), you can't "export" records as a FileMaker file.

Exporting the data gives you a choice of the usual file formats like text,
merge, Excel, SYLK, etc. for transporting text / numeric data to other
applications.

You can "Save As" the database file though, where you then get to choose
between clone, compressed, etc.

Helpful Harry )

Reply With Quote
  #9  
Old   
David Empson
 
Posts: n/a

Default Re: "Saving" data - 03-24-2010 , 02:12 PM



Your Name <your.name (AT) isp (DOT) com> wrote:

Quote:
"David Empson" <dempson (AT) actrix (DOT) gen.nz> wrote in message
news:1jfvi3m.retmgm1cp96x6N%dempson (AT) actrix (DOT) gen.nz...
Your Name <your.name (AT) isp (DOT) com> wrote:

Unless it's something added to the newer versions (and I haven't
looked in FileMaker 9), you can't "export" records as a FileMaker
file.

FileMaker Pro 7 and later can export as a FileMaker Pro database. It
produces a simple database with a single table containing the data from
the exported table.

Seems a bit of a silly addition (especially since you'd lose any the related
data) considering what else is still "missing". No doubt some people find it
useful, but it really just removes one step from an "Export to Excel, Import
to FileMaker" process ... although it would keep the Container Field data.

For that matter, so can FileMaker Pro 6. (Isn't that the version you are
running?)

Nope. I've got FileMaker 4 and 5.5.
Well you didn't look very hard. FileMaker Pro 5.5 has the same feature.

(I can't run FileMaker Pro 4 any more without digging out an older
computer.)

--
David Empson
dempson (AT) actrix (DOT) gen.nz

Reply With Quote
  #10  
Old   
Your Name
 
Posts: n/a

Default Re: "Saving" data - 03-24-2010 , 03:02 PM



"David Empson" <dempson (AT) actrix (DOT) gen.nz> wrote

Quote:
Your Name <your.name (AT) isp (DOT) com> wrote:

"105" <cortical (AT) internode (DOT) on.net> wrote in message
news:4ba94966$0$8836$c3e8da3 (AT) news (DOT) astraweb.com...
Your Name wrote:
In article <4ba7ee46$0$8825$c3e8da3 (AT) news (DOT) astraweb.com>, 105
cortical (AT) internode (DOT) on.net> wrote:
One problem with exporting though is that it doesn't work for
Container
field data.
In what way does it not work? Were you thinking that as exports
will
probably end up in a different location node in the file hierarchy,
that
data inserted into container fields as references, will lose the
links?
Which does not happen because of the location of the FM file, only
if
the referenced images/files themselves are moved. Or something
else?

Doe this need to be qualified with some historical version?

Stored graphics / sounds / etc. are not exported since obviously the
export file formats (Text, Merge, Excel, etc.) can't store them.

I'm not sure about linked files, presumably the link gets exported
as
normal text, but it may not be of much use depending on whether it's
linking the full file path or not, and whether or not the data is
imported
on the same computer.

If you need to transfer data between two FileMaker databases, then
it's
better to Import directly from the other databse, rather than export
and
then import.

perhaps the point being missed, is that the op wants to isolate a
record
subset. So it is not an issue of excel... Exporting as a FileMaker
file does export Stored graphics / sounds / etc.

Unless it's something added to the newer versions (and I haven't looked
in
FileMaker 9), you can't "export" records as a FileMaker file.

FileMaker Pro 7 and later can export as a FileMaker Pro database. It
produces a simple database with a single table containing the data from
the exported table.
Seems a bit of a silly addition (especially since you'd lose any the related
data) considering what else is still "missing". No doubt some people find it
useful, but it really just removes one step from an "Export to Excel, Import
to FileMaker" process ... although it would keep the Container Field data.




Quote:
For that matter, so can FileMaker Pro 6. (Isn't that the version you are
running?)
Nope. I've got FileMaker 4 and 5.5. One place I do work for did upgrade to
FileMaker 9 (rather expensively and pointlessly for them) a while back, but
I haven't had time to play with everything in it - it's mostly a case of
making changes to existing database converted from the original FileMaker
5.5 ones.

Helpful Harry )

Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.