macq@miguel.llnl.gov (Don MacQueen) (03/08/91)
The latest on my list of things Claris broke when they went from Filemaker II to Filemaker Pro: A database is sorted. You find a subset of the records. The found subset is NOT, I repeat NOT NOT NOT sorted in the original order. This is the most G.D stupid imbecilic asinine design decision I have run across in a long time. Because it means that EVERY time I find a subset I have to re-sort. And then when I go back to the original entire set, I have to re-sort AGAIN. Claris are you listening? USE YOUR BRAINS. -- flame off. **&%#%!&!!_)!%!@!_)(*^!&!&*!@&&(*&!@(*@!^) -------------------- Don MacQueen macq@miguel.llnl.gov --------------------
skip@claris.com (Brian Schipper) (03/09/91)
macq@miguel.llnl.gov (Don MacQueen) writes: >The latest on my list of things Claris broke when they went from Filemaker II >to Filemaker Pro: >A database is sorted. You find a subset of the records. The found subset is >NOT, I repeat NOT NOT NOT sorted in the original order. This is the most G.D >stupid imbecilic asinine design decision I have run across in a long time. >Because it means that EVERY time I find a subset I have to re-sort. And then >when I go back to the original entire set, I have to re-sort AGAIN. Thank you for your comments. While the behavior you describe may be annoying to you, it is the same way that FileMaker II behaved. It was not changed in FileMaker Pro. While we would have liked to change it so that the records would remain sorted after the find, we were somewhat limited by the existing architecture of FileMaker II. In order for us to retain the sort order after every find, we would need to automatically perform a sort after every find operation. This would slow down finding dramatically and would be annoying to some users. Hopefully in the future we will be able to change the architecture to make this work the way you would like. >Claris are you listening? USE YOUR BRAINS. >-- >flame off. **&%#%!&!!_)!%!@!_)(*^!&!&*!@&&(*&!@(*@!^) >-------------------- >Don MacQueen >macq@miguel.llnl.gov >-------------------- I understand your frustration, and I assure you that we are listening to your comments. Brian -- Internet: skip@claris.com AppleLink: SCHIPPER1
Lou@cup.portal.com (William Joseph Marriott) (03/09/91)
macq@miguel.llnl.gov (Don MacQueen) writes: > The latest on my list of things Claris broke when they went from > Filemaker II to Filemaker Pro: > > A database is sorted. You find a subset of the records. The found > subset is NOT, I repeat NOT NOT NOT sorted in the original order. FileMaker has *never* retained the sorted order of records after a Find. This is largely because FileMaker (all versions) is disk-based. When you perform a sort, the "ID Numbers" of the records are re-arranged, not the actual records. Thus, FileMaker uses the sorted "ID Number" list when displaying records. This is because re-arranging the actual records on your disk would take a long time. When you do a Find, the list of record ID numbers changes, and thus another sort is required to put them in order again. -Bill Marriott lou@cup.portal.com
mlbarrow@athena.mit.edu (Michael L Barrow) (03/09/91)
Since we are talking Claris flames, I might as well burn this one that has been brewing in my head for a few months now. We are using FMPro on a network and we use it to track the calls from our clients -- we are a support organization. Anyway, in addition to running FMPro to record the progress of problem resolution, we do other things with our client Macs (weird things), like running 8 or more apps at once. So anyway, there is this new feature in the Pro version where it politely jams all the clients accessing the database if it loses contact with one client. In addition, it puts a dialog up on the host saying something like: The host has lost contact with <foo>. All activities will be suspended until contact is restablished or you may disconnect this client by pressing the Disconnect button. There are problems with this in my book. I thought the whole point of client-server applications was to create a system in which a resource could be distributed among several clients and the clients should not notice each other (or not notice each other to a great extent, as in speed). WHY DOES ONE MACHINE CAUSE THE WHOLE SYSTEM TO LOSE? I spoke to some engineer at Claris and he said that this was their solution to the corrupted index problem of FMII. Has anyone else had this problem? Could someone from Claris shed some light on this, please?!?!?! Many thanks, Mike -- ======================================================================= | Michael L Barrow | "If any of the above offended you, it was | | <mlbarrow@mit.edu> | my idea to do it -- not MIT's" | |---------------------------------------------------------------------| | Consultant | MIT Computing Support Services (CSS) | | Member | Student Information Processing Board (SIPB) | | Student | Computer Engineering Major, '93 | =======================================================================
arie@eecs.umich.edu (Arie Covrigaru) (03/09/91)
I would also like to add a change in Filemaker Pro that was made to solve one problem and, in my opinion, created a bigger one. Because of the IW II's insistence on moving back and forth every time a new page starts, and the annoyance this caused users of Filemaker II who printed out hundreds of labels, Claris made the decision to spool the set of records needed to be printed to disk before actually sending them to the printer. The problem is that if one wants to print a few hundred records (as in invoices) one has to wait for a very very long time (as in almost an hour on a Mac SE) to see the first page printed out in an IW. Not only that but if something goes wrong (as in loosing connection with client) and something always goes wrong, one waited almost an hour and never saw any invoice coming out of that poor IW, and has to go through the process again (and time=invoice=money). Now, I admit that spooling is a nice idea, but half spooling is bad one. It is also nice to know that Claris wants to reinvent the wheel in Filemaker, they reinvented network filesharing and now spooling, but that I see it as their responsibility to make it as good or better than the existing software or concentrate in doing a good database management program and let the spooling to others. By the way, the explanation about the IW and the labels is from a letter from Claris as a response to a complaint. -- ============================================================================= Arie Covrigaru | University of Michigan AI Lab Phone: (313)763-1255 | Room 149, Advanced Technology Bldg. Internet: arie@eecs.umich.edu | 1101 Beal Ave., Ann Arbor, MI 48109 =============================================================================
skip@claris.com (Brian Schipper) (03/12/91)
mlbarrow@athena.mit.edu (Michael L Barrow) writes: >There are problems with this in my book. I thought the whole point of >client-server applications was to create a system in which a resource >could be distributed among several clients and the clients should not >notice each other (or not notice each other to a great extent, as in >speed). WHY DOES ONE MACHINE CAUSE THE WHOLE SYSTEM TO LOSE? Actually this is a "feature" that was inherited from FileMaker II. The host notifies clients periodically of changes in the database. When one of the clients is busy, it can cause a lockup for everyone. What we added for FM Pro is the alert that lets you know this is happening. As you pointed out, this is not an ideal solution, but it is an improvement over FileMaker II, since it does alert you to the source of the problem. Hopefully we'll be able to do better in a future release. Brian -- Internet: skip@claris.com AppleLink: SCHIPPER1
skip@claris.com (Brian Schipper) (03/12/91)
arie@eecs.umich.edu (Arie Covrigaru) writes: >I would also like to add a change in Filemaker Pro that was made to solve >one problem and, in my opinion, created a bigger one. Because of the >IW II's insistence on moving back and forth every time a new page starts, >and the annoyance this caused users of Filemaker II who printed out >hundreds of labels, Claris made the decision to spool the set of records >needed to be printed to disk before actually sending them to the printer. >Now, I admit that spooling is a nice idea, but half spooling is bad one. You make a good point. We decided to change the printing mechanism in response to complaints from ImageWriter users, but because of the reasons you pointed out, it is sometimes inconvenient. We hope to make this a preference in a future release so that everyone will be happy. Brian -- Internet: skip@claris.com AppleLink: SCHIPPER1
macq@miguel.llnl.gov (Don MacQueen) (03/13/91)
In article <200@claris.com>, skip@claris.com (Brian Schipper) writes: (in response to an earlier posting of mine) |> |> Thank you for your comments. While the behavior you describe may be annoying |> to you, it is the same way that FileMaker II behaved. It was not changed in |> FileMaker Pro. While we would have liked to change it so that the records |> would remain sorted after the find, we were somewhat limited by the |> existing architecture of FileMaker II. In order for us to retain the sort |> order after every find, we would need to automatically perform a sort |> after every find operation. This would slow down finding dramatically |> and would be annoying to some users. Hopefully in the future we will be |> able to change the architecture to make this work the way you would like. |> |> I understand your frustration, and I assure you that we are listening to |> your comments. |> |> Brian |> -- |> Internet: skip@claris.com AppleLink: SCHIPPER1 I appreciate the response from Brian. However, I've gone back and double-checked and verified my claim, using the same database, the same sort, and the same find. In FM II after a find, the records are still sorted in the original order. In FM Pro they are not. -- -------------------- Don MacQueen macq@miguel.llnl.gov --------------------
skip@claris.com (Brian Schipper) (03/14/91)
macq@miguel.llnl.gov (Don MacQueen) writes: >I appreciate the response from Brian. However, I've gone back and >double-checked and verified my claim, using the same database, the same sort, >and the same find. In FM II after a find, the records are still sorted in >the original order. In FM Pro they are not. I'm sorry to disagree with you, Dan, but FileMaker II does not retain the original sort order after a find. When you find records, the records that are found show up in the order that they were entered into the database. What may be happening is that this order happens to be the same as the order that you have sorted them by, but in general, this does not happen. Brian -- Internet: skip@claris.com AppleLink: SCHIPPER1
logic@wet.UUCP (Henry Kwan) (03/14/91)
I guess it's my turn to bitch about FileMaker Pro. The one thing which
really irks me about FM Pro is that lookup files have to be in the same
folder if FM Pro is to find them automatically. I use several databases
located in different folders which cross-reference each other and everytime
I use the databases, I have to manually located the lookup file since they
aren't in the same folder. A wee bit brain dead.
--
Henry Kwan | AppleLink: D0690 [] Bay BBS: (415)775-2384
FWB, Inc. | CompuServe: 71320,1034 [] FAX: (415)775-2225
2040 Polk St. Ste 215 | Internet: claris!wet!logic@ames.arc.nasa.gov
San Francisco, CA 94109 | UUCP: {claris,hoptoad,lamc,ucsfcca}!wet!logic