Re: The nightmare begins...
- From: Lynn Allen <lynn@xxxxxxxxxxxxxxxxx>
- Date: Wed, 2 Dec 2009 11:01:44 -0800
X-Trace
Approved
User-Agent: Unison/1.7.9
NNTP-Posting-Host: pool-71-189-194-236.lsanca.fios.verizon.net
X-Trace: news.bnb-lp.com 1259780502 pool-71-189-194-236.lsanca.fios.verizon.net (2 Dec 2009 14:01:42 -0500)
Lines: 138
X-Authenticated-User: vca037
X-DMCA-Complaints: Send abuse or DMCA complaints to abuse@xxxxxxxxxx
X-DMCA-Complaints: The subject line should contain only the 4 letters DMCA
Bytes: 8207
X-Original-Bytes: 8153
Path: mail.derkeiler.com!border1.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!feed.xsnews.nl!border-2.ams.xsnews.nl!feeder.news-service.com!news2.euro.net!newsfeed.kpn.net!pfeed09.wxs.nl!news.astraweb.com!border5.a.newsrouter.astraweb.com!tiscali!newsfeed2.ip.tiscali.net!nx01.iad01.newshosting.com!209.197.12.246.MISMATCH!nx02.iad01.newshosting.com!newshosting.com!novia!border2.nntp.dca.giganews.com!nntp.giganews.com!news.bnb-lp.com!not-for-mail
Xref: mail.derkeiler.com comp.databases.filemaker:120970
On 2009-12-01 21:57:46 -0800, Martin Trautmann <t-use@xxxxxxx> said:
On Tue, 1 Dec 2009 15:05:00 -0800, Lynn Allen wrote:On 2009-12-01 11:03:26 -0800, Martin Trautmann <t-use@xxxxxxx> said:
So IMHO FMP is a great tool for simple jobs. But it lacks everything
which would make it a professional tool.
There are plenty of professionals who would beg to differ, Martin.
Thanks, that's an answer that was to expect, not only here.
So may I ask how your backujp strategy is for a high reliablity
application?
High reliability requires more than backups. If you really want high reliability you're talking RAIDs and mirrored drives and sometimes even RAM disks, before you ever get to backups. I've never had a client who needed that level of reliability, but some developers I know have.
Then you need to talk about UPS's and network housekeeping and keeping the files available.
That said, FM Server 10 now offers features for creating timestamped and named backups on whatever schedule you want. Creation of off-site and separate media backups is left to whatever backup software you want to use. Newer versions of the software make backups much less intrusive than they used to be to users, so more frequent backups have a lot less impact on performance.
As for restoration of backups, if you've got sufficiently recent files, it can be as simple as copying the files into the proper directory and starting the server. If your files are not sufficiently recent, that's not FM's fault. You should backup (and preserve offsite, for disaster recovery) in direct proportion to how much work you (the business) can afford to re-create.
PHP now works with FM as a back-end, FM can work directly with SQL
tables, and increasingly, FM has become an excellent middle-ware for
linking disparate technologies and providing a quick and relatively
inexpensive to prototype & build in-house LAN solution with tentacles
all over the place.
I never managed to use the SQL system properly. It does support some
standard queries. Did you ever manage to migrate databases from SQL,
including create tables?
I've never seen the need to migrate. With ESS, you can now add SQL tables directly to the relationship graph, so that more than standard queries are available. The concept of shadow tables allows one to add FM-resident fields (and calculations) into the SQL tables to manipulate the data. Or, if one wants to work directly in FM, imports from SQL are lightning-fast, even for extremely large numbers of records.
If you want a spreadsheet, I suggest a spreadsheet. FM interfaces with
them directly too. Or you can use XML for communication between.
XML is a nice standard in order to have a standard. But its overhead is
huge. FMP does offer better spreadsheet like operation then most
spreadsheets I know when they introduced table views. But they stopped
at the single record, single cell edit behavior long time ago.
Spreadsheets are poor for database applications - but since most people
do not know any better, they use excel for database application. And
excel does become better and better there, offering improved filtering
mechanisms by now, where the spreadsheet does learn database operations.
And Excel does not only permit to export html format (with a huge
overload of Windows crap within the html code), but they manage much
better to import html as well - and they manage to copy/paste html
tables to the spreadsheet as well. I do not understand your logic that
you do approve html operations from a database, while you claim that
spreadsheet operations should be done by spreadsheets only.
I don't claim anything. You were wanting the spreadsheet-specific features of multi-cell editing and data movement. I suggest that if that is a requirement of your solution, that you do it in a program designed for it. If it's simply viewing the data, FM's table view does that admirably. With script triggers it's now possible to do amazing things in FM10, that can mimic a great many of Excel's features, but if you need a spreadsheet with specific spreadsheet features, use a spreadsheet.
I don't recommend FM as a page-layout app either. If that's what you need, move the data into a dedicated app, rather than trying to force FM into working in ways it's not intended to.
The reason so many people use Excel is that most office solutions start with a simple need to keep a list of something. Excel is excellent for this, and easy to use and understand. You can have a list up and running in Excel as fast as you can type.
Then the needs of the users and the business rules that have to be applied grow and develop and mutate, and at that point, Excel fails. This is the point where most independent developers come into a business and start building the first FM solution for a business. Once business rules and work process have to be integrated into the data, FM works admirably. It's not the only tool out there, and sometimes the data needs do mean that SQL is a better choice. But for in-house business enterprise needs, FM is usually the cheapest, quickest route to getting something done.
Many companies decide to use FM as a prototype tool, a proof-of-concept, with the idea of rebuilding it in SQL once the prototype is done. Then once it's built they find FM is doing fine, and the cost of the SQL solution (and the resultant inflexibility of the final product) is insupportable from a business viewpoint.
For companies who need flexible, easily changed or enhanced solutions, FM can be ideal. SQL, not so much.
Or so everyone I have encountered who tried to replace a FM solution
has found. After months or years, and thousands of dollars (sometimes
hundreds of thousands) the FM solutions are still chugging along, in
most cases.
Do you know some good Web databases which show the special power of
FMP10, compared to ordinary SQL databases? As soon as you do know and
use PHP, I wonder about the advantage of FMP as the base below.
The one that comes immediately to mind is:
http://www.shakeout.org/
This was a project aimed at an Oct 15, 2009 statewide (in California) earthquake preparedness drill. The site is still up and still apparently taking registrations for next year.
I am personally acquainted with the developer. The entire backend is FileMaker, and he said the site took nearly 7 MILLION registrations in the months leading up to the drill. Yes, Million.
--
Lynn Allen
--
www.semiotics.com
Member FBA
FM 10 Certified Developer
.
- References:
- The nightmare begins...
- From: ibgarrett
- Re: The nightmare begins...
- From: Lynn Allen
- The nightmare begins...
- Prev by Date: Re: Print Script Won't Work With More Than 1 Record
- Next by Date: how to list the layouts with portals
- Previous by thread: Re: The nightmare begins...
- Next by thread: Re: The nightmare begins...
- Index(es):
Relevant Pages
|