|
»
»
»
Faxing for FM9
|
View:
New views
13 Messages
—
Rating Filter:
Alert me
|
| < Prev | 1 - 2 | Next > |
 |
Re: tables and files (newbie)
by Bob Patin
::
Rate this Message:
It's not an easy job to combine separate files; like Patrick said, if
you have FMPA you can copy a table in file A and paste it into your new single file (file B). I've also used FMRobot, which is a really useful tool for this sort of thing; in a really large solution with lots of files, it can pay for itself in time saved... Patrick asked about the savings from 13 files to one; when we host a solution with up to 2 files, hosting is $39.95/month, as opposed to almost $90 more for 11 more files (we always discount that though). In some cases our clients have opted not to combine files, either because they didn't want to spend the money to have us consolidate them, or their original programming was so goofy that it didn't make sense to combine 4 piles of bad scripting into one huge pile of bad scripting... :) Bob Patin Longterm Solutions bob@... 615-333-6858 http://www.longtermsolutions.com iChat: bobpatin AIM: longterm1954 FileMaker 9 Certified Developer Member of FileMaker Business Alliance and FileMaker TechNet -------------------------- FileMaker hosting and consulting for all versions of FileMaker PHP • Full email services • Free DNS hosting • Colocation • Consulting On Jul 18, 2008, at 11:12 AM, Patrick Neame wrote: > Do you have FM Advanced? If you're a developer it's worth the extra > and you can just import the tables etc. There was some discussion > about it here:- > > Nabble - Layout Importing > > Another reason connected with what Bob said about IWP is that a file > that's served using IWP can't access data in a calculated field from > another file. It can see that data in another table in the same > file. Believe me, it's easier to do it now rather than redo it when > you finally realise that IWP is for you because it's a lot less > struggle and cheaper than learning or using PHP or whatever ju-ju is > out there. > > I've recently been through this with some files that were originally > created in FM6. (It took some time to catch up.) I looked at our > data and decided there were some obvious groups of files to merge > into one table. In the end I think I reduced it from 13 down to one. > (What's the saving Bob?) Some files, such as our theatre archive are > on their own and will stay that way. For one thing it's huge, but > for another it makes sense for it to be kept separate from a crash > protection point of view. Sure we have backups, but it's nice to > know that if the main file goes down it's unlikely to take years and > years of archive data with it. > > > Patrick Neame > www.incamera.co.uk - 07 957 463 933 > > > > On Jul 18, 2008, at 4:45 pm, Jim Guinness wrote: > >> Hey, those are great reasons! >> >> What's the simplest way to take files that are now separate disk >> files and incorporate them into an existing FM file? >> >> Jim >> >> >> At 7/18/2008 11:18 AM, you wrote: >>> Jim, >>> >>> I can think of about a half-dozen reasons why you'd want to use a >>> single file for your solution: >>> >>> 1. If you ever decide to host your solution with a web hosting >>> company >>> (like us, of course!), we all charge by the # of files. More files, >>> more expense. >>> >>> 2. Manageability- all of your scripts will be in one place, making >>> the >>> writing of new scripts or procedures much easier in a single file. >>> Just with the number of windows that you have to open, you reduce >>> the >>> complexity; with a 3-file solution, when you're writing scripts, >>> you'd >>> need to access 3 sets of scripts--3 windows. If you get into lots of >>> tables, you can imagine how this will make a difference. >>> >>> 3. Reusability - with a single file, it's much easier to write >>> reuseable scripts, for example a script that can perform searches on >>> any table in your solution, or perhaps a navigation script for >>> getting >>> around in your solution with a standard set of buttons on each >>> layout. >>> >>> 4. Account management - each file you introduce into your solution >>> is >>> going to require account management, which means if you get into >>> lots >>> of user accounts, you'll have to duplicate this in every file in >>> your >>> solution. There are some great new workarounds for this, but >>> generally >>> this is what you'd have to deal with. >>> >>> 5. IWP - if you ever want to use Instant Web Publishing, you have to >>> present a unified database to the browser. Again, there are >>> workarounds for this (an interface file), but it's still another >>> reason to stick with a single file for your solution. >>> >>> 6. Ease of use - I find it much easier to work with a single file, >>> for >>> things like copying fields, scripts, layouts; sure, you can do that >>> with multiple files easily enough, but I always find that easier >>> with >>> a single file, from which I can open multiple windows if need be. >>> >>> That's a half-dozen; if I sat here and thought about it, I'd come up >>> with a half-dozen more in no time. >>> >>> Hope that helps, >>> >>> Bob Patin >>> Longterm Solutions >>> bob@... >>> 615-333-6858 >>> http://www.longtermsolutions.com >>> iChat: bobpatin >>> AIM: longterm1954 >>> FileMaker 9 Certified Developer >>> Member of FileMaker Business Alliance and FileMaker TechNet >>> -------------------------- >>> FileMaker hosting and consulting for all versions of FileMaker >>> PHP • Full email services • Free DNS hosting • Colocation • >>> Consulting >>> >>> >>> >>> On Jul 16, 2008, at 11:16 PM, Jim Guinness wrote: >>> >>>> Hi, >>>> >>>> Filemaker's docs seem pretty equivocal about whether to put tables >>>> in separate files or all in one file, and I'm trying to understand >>>> this issue better. >>>> >>>> I'm designing a fairly simple app (my first in FM, though I've done >>>> a lot of non-FM work) which, for the time being at least, is pretty >>>> much a flat file. There are a handful of files that hold looked-up >>>> data and the like, but I never expect this to get very complex. >>>> >>>> I've put my different tables in separate files because it seems >>>> natural to do so and because I don't know of any reason not to. I >>>> notice David Kachel in his "White Paper for FMP Novices" strongly >>>> recommends putting all tables in one file whenever possible ... >>>> though he seems to be writing to developers (which I'm currently >>>> not, being an ex-developer who's writing an app for a new business >>>> venture.) >>>> >>>> Anyway, when and why is it preferable to put tables in one file >>>> rather than each table in its own file? I'm just getting used to >>>> how >>>> FM "thinks" and I like what I'm understanding of it, but this piece >>>> is still eluding me. >>>> >>>> Thanks in advance. >>>> >>>> Jim Guinness >>>> _______________________________________________ >>>> FMPexperts mailing list >>>> FMPexperts@... >>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts- >>>> ironclad.net.au >>> >>> _______________________________________________ >>> FMPexperts mailing list >>> FMPexperts@... >>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au >> _______________________________________________ >> FMPexperts mailing list >> FMPexperts@... >> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au > > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: tables and files (newbie)
by Bruce Robertson
::
Rate this Message:
> It's not an easy job to combine separate files; like Patrick said, if
> you have FMPA you can copy a table in file A and paste it into your > new single file (file B). Or you can just import them as new tables; which can be done with the regular version of Filemaker. _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
RE: tables and files (newbie)
by VanBuskirk, Patricia
::
Rate this Message:
One of the biggest hassles I've found in combining files is recreating
all the value lists! -----Original Message----- From: fmpexperts-bounces@... [mailto:fmpexperts-bounces@...] On Behalf Of Bruce Robertson Sent: Friday, July 18, 2008 1:30 PM To: fmpexperts@... Subject: Re: tables and files (newbie) > It's not an easy job to combine separate files; like Patrick said, if > you have FMPA you can copy a table in file A and paste it into your > new single file (file B). Or you can just import them as new tables; which can be done with the regular version of Filemaker. _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: tables and files (newbie)
by Tom Fitch-3
::
Rate this Message:
>>> Anyway, when and why is it preferable to put tables in one file
>>> rather than each table in its own file? I may have missed it, but one reason I didn't see mentioned yet is: custom functions. They can't be easily copied from file to file. Same goes for value lists. Tom Fitch FileMaker 7/8/9 Certified Developer Fiddlehead Software Portland, Oregon _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: tables and files (newbie)
by Bob Patin
::
Rate this Message:
Yes, it would really be nice to have an IMPORT command for importing
functions. Perhaps that will be forthcoming... Bob Patin Longterm Solutions bob@... 615-333-6858 http://www.longtermsolutions.com iChat: bobpatin AIM: longterm1954 FileMaker 9 Certified Developer Member of FileMaker Business Alliance and FileMaker TechNet -------------------------- FileMaker hosting and consulting for all versions of FileMaker PHP • Full email services • Free DNS hosting • Colocation • Consulting On Jul 18, 2008, at 12:51 PM, Tom Fitch wrote: > > I may have missed it, but one reason I didn't see mentioned yet is: > custom functions. They can't be easily copied from file to file. _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: tables and files (newbie)
by Bart Bartholomay
::
Rate this Message:
If you guys are developing on a Mac (and who wouldn't elect to?) spend
$43 and get Clip Manager from myFMButler. It does a great job of this and a whole bunch of other nice to have utilities. Bart On Jul 20, 2008, at 8:12 PM, Bob Patin/Longterm Solutions wrote: > Yes, it would really be nice to have an IMPORT command for importing > functions. Perhaps that will be forthcoming... > > Bob Patin > Longterm Solutions > bob@... > 615-333-6858 > http://www.longtermsolutions.com > iChat: bobpatin > AIM: longterm1954 > FileMaker 9 Certified Developer > Member of FileMaker Business Alliance and FileMaker TechNet > -------------------------- > FileMaker hosting and consulting for all versions of FileMaker > PHP • Full email services • Free DNS hosting • Colocation • Consulting > > On Jul 18, 2008, at 12:51 PM, Tom Fitch wrote: > >> >> I may have missed it, but one reason I didn't see mentioned yet is: >> custom functions. They can't be easily copied from file to file. > > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: tables and files (newbie)
by David Buck-2
::
Rate this Message:
The biggest argument I can think of against single file solutions is
the implication for tape backups. For example, If you have a 500 MB single file solution and change 1 single character in a single field of a single record in that single file, the whole 500 MB shebang will be backed up again on your next backup run. However, if you split your tables into logical files, then only the modified file will be backed up. An argument for the separation model (where a separate interface file is used, with a single data file or multiple data files) is where bandwidth is at a premium, eg. over VPN. The separation model allows interface elements (often graphics-heavy) to be stored locally so they do not have to be repeatedly transferred over the network. I am not advocating multiple over single file solutions, but I didn't see the above points yet mentioned explicitly in this discussion. David. _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: tables and files (newbie)
by Winfried Huslik
::
Rate this Message:
David,
This logic does not apply here. A FileMaker file is not a text file. Every time you open a FM file and do the slightest action with it (search, print), it will be modified in more than one place and possibly reorganized in many places. Backups in FileMaker should not be done on a "being modified" basis (and god forbid saving just the differences), but always as a whole solution with all files involved - and always from the FileMaker Server provided backups, but never from the running solution, which likely would make them unusable. Nowadays backup space should not be a concern, and who uses "tapes" anyway. Winfried www.fmdiff.com On 23.07.2008, at 15:52, David Buck wrote: > The biggest argument I can think of against single file solutions > is the implication for tape backups. > > For example, If you have a 500 MB single file solution and change 1 > single character in a single field of a single record in that > single file, the whole 500 MB shebang will be backed up again on > your next backup run. However, if you split your tables into > logical files, then only the modified file will be backed up. > > An argument for the separation model (where a separate interface > file is used, with a single data file or multiple data files) is > where bandwidth is at a premium, eg. over VPN. The separation model > allows interface elements (often graphics-heavy) to be stored > locally so they do not have to be repeatedly transferred over the > network. > > I am not advocating multiple over single file solutions, but I > didn't see the above points yet mentioned explicitly in this > discussion. > > David. FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: tables and files (newbie)
by Bob Patin
::
Rate this Message:
I second what Winfried has said; with FileMaker Server, it's a simple
matter to have backups occurring on a regular basis (our company backs up all databases every hour, to 3 separate drives). If a database solution has any significant importance to an organization, it should be running on FileMaker Server and not directly from a hard drive using FileMaker Pro. Key reasons for this include not only the backup issue, but corruption issues, accesibility, and so on. While there are clear uses for the data-separation model, I don't think that was the central issue here... Bob Patin Longterm Solutions bob@... 615-333-6858 http://www.longtermsolutions.com iChat: bobpatin AIM: longterm1954 FileMaker 9 Certified Developer Member of FileMaker Business Alliance and FileMaker TechNet -------------------------- FileMaker hosting and consulting for all versions of FileMaker PHP • Full email services • Free DNS hosting • Colocation • Consulting On Jul 23, 2008, at 7:38 PM, Winfried Huslik wrote: > David, > > This logic does not apply here. A FileMaker file is not a text file. > > Every time you open a FM file and do the slightest action with it > (search, print), it will be modified in more than one place and > possibly reorganized in many places. > > Backups in FileMaker should not be done on a "being modified" basis > (and god forbid saving just the differences), but always as a whole > solution with all files involved - and always from the FileMaker > Server provided backups, but never from the running solution, which > likely would make them unusable. > > Nowadays backup space should not be a concern, and who uses "tapes" > anyway. > > > Winfried > www.fmdiff.com > > > > > On 23.07.2008, at 15:52, David Buck wrote: > >> The biggest argument I can think of against single file solutions >> is the implication for tape backups. >> >> For example, If you have a 500 MB single file solution and change 1 >> single character in a single field of a single record in that >> single file, the whole 500 MB shebang will be backed up again on >> your next backup run. However, if you split your tables into >> logical files, then only the modified file will be backed up. >> >> An argument for the separation model (where a separate interface >> file is used, with a single data file or multiple data files) is >> where bandwidth is at a premium, eg. over VPN. The separation model >> allows interface elements (often graphics-heavy) to be stored >> locally so they do not have to be repeatedly transferred over the >> network. >> >> I am not advocating multiple over single file solutions, but I >> didn't see the above points yet mentioned explicitly in this >> discussion. >> >> David. > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
RE: tables and files (newbie)
by Robertson, Forbes-2
::
Rate this Message:
Regarding the tapes comment.
How else do you offsite backups? And tapes are quite robust. Tapes have their palace in a backup strategy, but certainly aren't the only solution. There was a recent article in PC Pro about how physically fragile the high capacity external Hard Disks are. A bang to a desk can be enough to break them. Personally I use a mix of RAID, copies to other servers, rotated tapes and occasional CD backups. Forbes -----Original Message----- From: fmpexperts-bounces@... [mailto:fmpexperts-bounces@...] On Behalf Of Winfried Huslik Sent: 24 July 2008 01:39 To: fmpexperts@... Subject: Re: tables and files (newbie) David, This logic does not apply here. A FileMaker file is not a text file. Every time you open a FM file and do the slightest action with it (search, print), it will be modified in more than one place and possibly reorganized in many places. Backups in FileMaker should not be done on a "being modified" basis (and god forbid saving just the differences), but always as a whole solution with all files involved - and always from the FileMaker Server provided backups, but never from the running solution, which likely would make them unusable. Nowadays backup space should not be a concern, and who uses "tapes" anyway. Winfried www.fmdiff.com On 23.07.2008, at 15:52, David Buck wrote: > The biggest argument I can think of against single file solutions > is the implication for tape backups. > > For example, If you have a 500 MB single file solution and change 1 > single character in a single field of a single record in that > single file, the whole 500 MB shebang will be backed up again on > your next backup run. However, if you split your tables into > logical files, then only the modified file will be backed up. > > An argument for the separation model (where a separate interface > file is used, with a single data file or multiple data files) is > where bandwidth is at a premium, eg. over VPN. The separation model > allows interface elements (often graphics-heavy) to be stored > locally so they do not have to be repeatedly transferred over the > network. > > I am not advocating multiple over single file solutions, but I > didn't see the above points yet mentioned explicitly in this > discussion. > > David. FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au -- ******************************************************************************** The information in this email and any files transmitted with it is confidential and may be legally privileged. It is intended solely for the addressee and others authorised to receive it. If you are not the intended recipient,, any disclosure, copying, distribution or action taken in reliance on its contents is prohibited and may be unlawful. Prospects Services Limited is a limited company registered in England and Wales. Reg No: 3042176 Registered Office: Prospects House, 19 Elmfield Road, Bromley, BR1 1LT. If you have received this email in error please notify: postmaster@... http://www.prospects.co.uk This footnote also confirms that this email message has been swept for the presence of computer viruses ******************************************************************************** _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: tables and files (newbie)
by Troy Hyde: Sun Door and Trim, Inc.
::
Rate this Message:
CrashPlan is a Great offsite_Through_internet service. There is a one time
license charge, and you can backup to another machine of yours, or to their server(charge) I use crash plan on all 10+ of my machines and use it at my office with 20+ machines, all continuously backing up to a machine that has 2 RAID and Time Machine. On 7/24/08 1:44 AM, "Robertson, Forbes" <Forbes.Robertson@...> wrote: > Regarding the tapes comment. > > How else do you offsite backups? And tapes are quite robust. Tapes have > their palace in a backup strategy, but certainly aren't the only > solution. > > There was a recent article in PC Pro about how physically fragile the > high capacity external Hard Disks are. A bang to a desk can be enough to > break them. > > Personally I use a mix of RAID, copies to other servers, rotated tapes > and occasional CD backups. > > Forbes > > > > -----Original Message----- > From: fmpexperts-bounces@... > [mailto:fmpexperts-bounces@...] On Behalf Of Winfried > Huslik > Sent: 24 July 2008 01:39 > To: fmpexperts@... > Subject: Re: tables and files (newbie) > > David, > > This logic does not apply here. A FileMaker file is not a text file. > > Every time you open a FM file and do the slightest action with it > (search, print), it will be modified in more than one place and > possibly reorganized in many places. > > Backups in FileMaker should not be done on a "being modified" basis > (and god forbid saving just the differences), but always as a whole > solution with all files involved - and always from the FileMaker > Server provided backups, but never from the running solution, which > likely would make them unusable. > > Nowadays backup space should not be a concern, and who uses "tapes" > anyway. > > > Winfried > www.fmdiff.com > > > > > On 23.07.2008, at 15:52, David Buck wrote: > >> The biggest argument I can think of against single file solutions >> is the implication for tape backups. >> >> For example, If you have a 500 MB single file solution and change 1 >> single character in a single field of a single record in that >> single file, the whole 500 MB shebang will be backed up again on >> your next backup run. However, if you split your tables into >> logical files, then only the modified file will be backed up. >> >> An argument for the separation model (where a separate interface >> file is used, with a single data file or multiple data files) is >> where bandwidth is at a premium, eg. over VPN. The separation model >> allows interface elements (often graphics-heavy) to be stored >> locally so they do not have to be repeatedly transferred over the >> network. >> >> I am not advocating multiple over single file solutions, but I >> didn't see the above points yet mentioned explicitly in this >> discussion. >> >> David. > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au > > -- > ****************************************************************************** > ** > > The information in this email and any files transmitted with it is > confidential > and may be legally privileged. It is intended solely for the addressee and > others authorised to receive it. > > If you are not the intended recipient,, any disclosure, copying, distribution > or > action taken in reliance on its contents is prohibited and may be unlawful. > > Prospects Services Limited is a limited company registered in England and > Wales. > > Reg No: 3042176 > Registered Office: Prospects House, 19 Elmfield Road, Bromley, BR1 1LT. > > If you have received this email in error please notify: > > postmaster@... > > http://www.prospects.co.uk > > This footnote also confirms that this email message has been swept for the > presence of computer viruses > > ****************************************************************************** > ** > > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au > -- Troy Hyde Sun Door and Trim, Inc. TroyEHyde@... Sun Door and Trim, Inc. 1522 East Victory Street Suite #5 Phoenix, AZ 85040 ROC091522 Commercial ROC091517 Residential (602) 305-8050 ext 11 Tel. (602) 305-8292 Fax. www.sundoorandtrim.com _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
RE: tables and files (newbie)
by Robertson, Forbes-2
::
Rate this Message:
How long would a full restore take off one of these internet based
options? I back some files up over the internet, but only as a secondary backup. Forbes -----Original Message----- From: fmpexperts-bounces@... [mailto:fmpexperts-bounces@...] On Behalf Of Troy Hyde: Sun Door and Trim, Inc. Sent: 24 July 2008 15:33 To: fmpexperts@... Subject: Re: tables and files (newbie) CrashPlan is a Great offsite_Through_internet service. There is a one time license charge, and you can backup to another machine of yours, or to their server(charge) I use crash plan on all 10+ of my machines and use it at my office with 20+ machines, all continuously backing up to a machine that has 2 RAID and Time Machine. On 7/24/08 1:44 AM, "Robertson, Forbes" <Forbes.Robertson@...> wrote: > Regarding the tapes comment. > > How else do you offsite backups? And tapes are quite robust. Tapes have > their palace in a backup strategy, but certainly aren't the only > solution. > > There was a recent article in PC Pro about how physically fragile the > high capacity external Hard Disks are. A bang to a desk can be enough to > break them. > > Personally I use a mix of RAID, copies to other servers, rotated tapes > and occasional CD backups. > > Forbes > > > > -----Original Message----- > From: fmpexperts-bounces@... > [mailto:fmpexperts-bounces@...] On Behalf Of > Huslik > Sent: 24 July 2008 01:39 > To: fmpexperts@... > Subject: Re: tables and files (newbie) > > David, > > This logic does not apply here. A FileMaker file is not a text file. > > Every time you open a FM file and do the slightest action with it > (search, print), it will be modified in more than one place and > possibly reorganized in many places. > > Backups in FileMaker should not be done on a "being modified" basis > (and god forbid saving just the differences), but always as a whole > solution with all files involved - and always from the FileMaker > Server provided backups, but never from the running solution, which > likely would make them unusable. > > Nowadays backup space should not be a concern, and who uses "tapes" > anyway. > > > Winfried > www.fmdiff.com > > > > > On 23.07.2008, at 15:52, David Buck wrote: > >> The biggest argument I can think of against single file solutions >> is the implication for tape backups. >> >> For example, If you have a 500 MB single file solution and change 1 >> single character in a single field of a single record in that >> single file, the whole 500 MB shebang will be backed up again on >> your next backup run. However, if you split your tables into >> logical files, then only the modified file will be backed up. >> >> An argument for the separation model (where a separate interface >> file is used, with a single data file or multiple data files) is >> where bandwidth is at a premium, eg. over VPN. The separation model >> allows interface elements (often graphics-heavy) to be stored >> locally so they do not have to be repeatedly transferred over the >> network. >> >> I am not advocating multiple over single file solutions, but I >> didn't see the above points yet mentioned explicitly in this >> discussion. >> >> David. > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au > > -- > ****** > ** > > The information in this email and any files transmitted with it is > confidential > and may be legally privileged. It is intended solely for the addressee and > others authorised to receive it. > > If you are not the intended recipient,, any disclosure, copying, distribution > or > action taken in reliance on its contents is prohibited and may be unlawful. > > Prospects Services Limited is a limited company registered in England and > Wales. > > Reg No: 3042176 > Registered Office: Prospects House, 19 Elmfield Road, Bromley, BR1 1LT. > > If you have received this email in error please notify: > > postmaster@... > > http://www.prospects.co.uk > > This footnote also confirms that this email message has been swept for the > presence of computer viruses > > ************************************************************************ ****** > ** > > _______________________________________________ > FMPexperts mailing list > FMPexperts@... > http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au > -- Troy Hyde Sun Door and Trim, Inc. TroyEHyde@... Sun Door and Trim, Inc. 1522 East Victory Street Suite #5 Phoenix, AZ 85040 ROC091522 Commercial ROC091517 Residential (602) 305-8050 ext 11 Tel. (602) 305-8292 Fax. www.sundoorandtrim.com _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
|
|
Re: tables and files (newbie)
by Troy Hyde: Sun Door and Trim, Inc.
::
Rate this Message:
Depending on the size of the restore... And your internet connection....
If I am restoring (1)one file 5MB it is 20seconds. Also, If you needed a complete restore... You can restore it to the offsite machine, and use that as the temp replacement. Another benefit to CrashPLan in particular is that it will save as many versions of the file as you'd like. So when I open **FILEx** I see all the different versions, and I can pick which version I would like to restore. This is a great feature, as I am sure you know, often with files that aren't used everyday, you can have a corrupted file for 1week, which could have been backed up 3-4 times over. Troy. On 7/24/08 7:35 AM, "Robertson, Forbes" <Forbes.Robertson@...> wrote: > How long would a full restore take off one of these internet based > options? > > I back some files up over the internet, but only as a secondary backup. > > Forbes > > -----Original Message----- > From: fmpexperts-bounces@... > [mailto:fmpexperts-bounces@...] On Behalf Of Troy > Hyde: Sun Door and Trim, Inc. > Sent: 24 July 2008 15:33 > To: fmpexperts@... > Subject: Re: tables and files (newbie) > > CrashPlan is a Great offsite_Through_internet service. There is a one > time > license charge, and you can backup to another machine of yours, or to > their > server(charge) > > I use crash plan on all 10+ of my machines and use it at my office with > 20+ > machines, all continuously backing up to a machine that has 2 RAID and > Time > Machine. > > > On 7/24/08 1:44 AM, "Robertson, Forbes" > <Forbes.Robertson@...> > wrote: > >> Regarding the tapes comment. >> >> How else do you offsite backups? And tapes are quite robust. Tapes > have >> their palace in a backup strategy, but certainly aren't the only >> solution. >> >> There was a recent article in PC Pro about how physically fragile the >> high capacity external Hard Disks are. A bang to a desk can be enough > to >> break them. >> >> Personally I use a mix of RAID, copies to other servers, rotated tapes >> and occasional CD backups. >> >> Forbes >> >> >> >> -----Original Message----- >> From: fmpexperts-bounces@... >> [mailto:fmpexperts-bounces@...] On Behalf Of > Winfried >> Huslik >> Sent: 24 July 2008 01:39 >> To: fmpexperts@... >> Subject: Re: tables and files (newbie) >> >> David, >> >> This logic does not apply here. A FileMaker file is not a text file. >> >> Every time you open a FM file and do the slightest action with it >> (search, print), it will be modified in more than one place and >> possibly reorganized in many places. >> >> Backups in FileMaker should not be done on a "being modified" basis >> (and god forbid saving just the differences), but always as a whole >> solution with all files involved - and always from the FileMaker >> Server provided backups, but never from the running solution, which >> likely would make them unusable. >> >> Nowadays backup space should not be a concern, and who uses "tapes" >> anyway. >> >> >> Winfried >> www.fmdiff.com >> >> >> >> >> On 23.07.2008, at 15:52, David Buck wrote: >> >>> The biggest argument I can think of against single file solutions >>> is the implication for tape backups. >>> >>> For example, If you have a 500 MB single file solution and change 1 >>> single character in a single field of a single record in that >>> single file, the whole 500 MB shebang will be backed up again on >>> your next backup run. However, if you split your tables into >>> logical files, then only the modified file will be backed up. >>> >>> An argument for the separation model (where a separate interface >>> file is used, with a single data file or multiple data files) is >>> where bandwidth is at a premium, eg. over VPN. The separation model >>> allows interface elements (often graphics-heavy) to be stored >>> locally so they do not have to be repeatedly transferred over the >>> network. >>> >>> I am not advocating multiple over single file solutions, but I >>> didn't see the above points yet mentioned explicitly in this >>> discussion. >>> >>> David. >> _______________________________________________ >> FMPexperts mailing list >> FMPexperts@... >> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au >> >> -- >> > ************************************************************************ > ****** >> ** >> >> The information in this email and any files transmitted with it is >> confidential >> and may be legally privileged. It is intended solely for the > addressee and >> others authorised to receive it. >> >> If you are not the intended recipient,, any disclosure, copying, > distribution >> or >> action taken in reliance on its contents is prohibited and may be > unlawful. >> >> Prospects Services Limited is a limited company registered in England > and >> Wales. >> >> Reg No: 3042176 >> Registered Office: Prospects House, 19 Elmfield Road, Bromley, BR1 > 1LT. >> >> If you have received this email in error please notify: >> >> postmaster@... >> >> http://www.prospects.co.uk >> >> This footnote also confirms that this email message has been swept for > the >> presence of computer viruses >> >> > ************************************************************************ > ****** >> ** >> >> _______________________________________________ >> FMPexperts mailing list >> FMPexperts@... >> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au >> -- Troy Hyde Sun Door and Trim, Inc. TroyEHyde@... Sun Door and Trim, Inc. 1522 East Victory Street Suite #5 Phoenix, AZ 85040 ROC091522 Commercial ROC091517 Residential (602) 305-8050 ext 11 Tel. (602) 305-8292 Fax. www.sundoorandtrim.com _______________________________________________ FMPexperts mailing list FMPexperts@... http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au |
| < Prev | |