From: Brad A. <bra...@ma...> - 2004-09-14 04:08:29
|
I'm right there with you, Norman. That summation of the FileMaker situation is pretty much dead-on. >Kevin Altis asked: > >>In particular, I would like to hear about features that products >>like FileMaker Pro provide that are needed for an OS tool that >>users could transition to without feeling like they are taking a >>step backwards. >> > >I'd like to start more positively. My major client would forgive a >great deal if he got more speed. And I'm pretty sure he will get it >if I go down this, the Python/PythonCard, road. I start with this >comment as much of what Filemaker does is probably not worth >reproducing providing the user experience in the new environment is >perceived as positive. > >Filemaker 7 has just come out and it is much slower than version 6. >On moving to OS X we already took a speed hit so, in the four years >I have been working on this thing, instead of hardware improvements >making things slick it has all got slower. On top of this, FM7 >requires relearning much of what one has done + obliges a rewrite. >Hence the reason my search is on. > >I looked at many possibilities, some commercial, some open source. >The reasons my quest has brought me here are: > >1) I liked python from the moment I started to play with it. >2) one of the wx demos (then on OS X - now working mainly on a PC) >showed some really rapid responsiveness to events. > > >Here is what Filemaker gives: > >No need to define field lengths for any type of field. This seems >trivial but gives an amazing freedom in database design. > >Pretty maintenance free. Most sites have no database expert. I have >never lost data (have come pretty close). However, no rollback. > >Almost transparently cross platform - some font and printing issues. >But client (as opposed to FM Server) not available on Linux. This >latter is political as, now that the Mac is Unix based, doing the >port would involve little work. > >No connection hassles. FM mixes data, scripts, layouts and stuff all >in one file per database (in FM7 this become per table). > >An integrated form designer that, being designed for the purpose of >databases, is pretty easy to use. >Same tool is used to design reports. > >A relationship model that makes one to one, one to many, many to >many, many to one relationships pretty easy to get a grasp of. (At >least that's how it seems now, looking back). > >Where SQL would use scripts (I believe) to select a group of >records, FM frequently uses calculation fields as part of the >relationship. > >Calculations can appear in scripts as well as field definitions. >These make great use of an extensive set of 'Status' functions. > >FM is responsive to what is showing on the screen. If you haven't >seen this it needs some explanation. If you go to a layout that >contains references to another file(file = table in version < 7) >then that file gets opened. If you open that layout in a small >window only what is showing and referenced gets opened. > >Pretty neat pop-up lists that can be up to 64k characters (much more >in v7). On clicking in a field that has a pop-up the list becomes >live to the keyboard i.e. typing 'be' takes one to entries beginning >with 'be'. These lists can be based on >a) custom values >b) a value list from another file >c) the values from a field >d) the values from a field via a relationship. >One pretty neat thing here is that a relationship can be defined >from virtually anywhere - deep withing the creation of a value list >or during field definition or script creation. > >However, there is no inbuilt type-ahead searching. > > >What is horrible and nasty: > >No event based scripting. > >No automated field or layout creation. Nothing of this type can be >done on the fly. > >Can't get at the controls when some speed tweaks are needed. > >Incremental back ups are difficult to implement. Built in back up >method can be slow as much more than the raw data is getting backed >up. Can export fields and specify just data fields. Problem is that >this process cannot be dynamically scripted. > >Wide area network performance is lamentable as, at start up, the >whole caboodle has to be dragged over the wires before anything >happens. (This is another one that would lead my client to accept >re-learning an interface) > >Every user has to have a full copy of FM - form designer, script >maker et al included. This is expensive and adds unnecessary >security risks (there is a so-called kiosk version but these are not >net workable). > >Limited ability to produce dynamic dialogues. > >Poor documentation once above novice level. Poor response to bugs >and queries from FM, the company. (Happily, there are a couple of >good lists). > >Can't save or access scripts as text so can't cut and past chunks. > >Until v7, no application wide globals, no parameters for scripts (a >nightmare). > >Oh, I forgot - no variables. Filemaker uses what it call 'global >fields' for this. A real pain. > >No regular expression searches. No wildcards. > >__________________- > >Apologies if I have been too detailed or not enough. > >With all those downers some of you must be wondering why there is >hesitation. It is worth noting that most Filemaker developers are >doing quite nicely. FM, once mainly a Mac thing, now has 80% of new >sales on Windows. And sales are (or at least, were, up till v7) >growing fast. Many of these new users are tempted in by the ease >with which rudimentary databases can be produced. They then come >searching for guys like me when things get more complicated (as they >inevitably do), > >Norman Winn > > > > > >------------------------------------------------------- >This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 >Project Admins to receive an Apple iPod Mini FREE for your judgement on >who ports your project to Linux PPC the best. Sponsored by IBM. >Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php >_______________________________________________ >Pythoncard-users mailing list >Pyt...@li... >https://lists.sourceforge.net/lists/listinfo/pythoncard-users |