DozerHozer

Foodsman: As for stability, Helix is very solid. As was mentioned, Helix can be set up with a log file that records all transactions so that if the system crashes, plug is pulled, etc. before the user did a save, all transactions up to that point are re-entered automatically when the database is next launched. There are also a couple of utilities included with it that should be used regularly to scan for and clean up major or minor problems that may creep in due to bad bits on a disk, cosmic rays, phase of the moon - whatever :-) And if all else fails (which can happen with any database) and file corruption occurs which cannot be fixed locally, you can send your database into Helix tech support and, for a reasonable price, they will fix it if at all possible. Think of it as sending in a disk drive to DriveSavers after you dropped it in your fish tank. And, tech support for Helix development is very knowledgeable, helpful and responsive. Stability is something I generally don't worry about with Helix. However, anyone thinking of moving to Helix (especially in a big way such as you've described with your 88 clients) is the long term outlook for the company. I am a strong supporter of Helix, love it, and would love to see more folks using it. The more who use it, the better its chances for the future. However, I'm also a realist. And over the years, Helix's fortunes have been a roller coaster ride. Right now, its prospects look good and the people steering the ship are "true believers" who will do everything they can to ensure a bright future. But it will take some time for them to prove themselves capable of persevering for the long haul, and having the business and marketing savvy to make it work. If I had a client/server app with an installed base of 88 users and I was considering moving to a new database platform, I would consider Helix a good choice technically, but a bit risky on the business side. Moving to ANY new database is a huge investment in learning curve and transitional development. Only you can decide whether it is worth it. If you're interested, I would suggest purchasing the RADE piece and try your hand on a small project. Work your way up, learning some of the more advanced concepts before making a decision. While the manual is good for a starting reference, the Helix List is where you'll find lots of people willing and able to help you get a leg up, whether its beginners help, or learning some of Helix's more powerful features.

I too am a long time Helix user and have dabbled in FMPro from time to time. Once, when Helix's future was uncertain, I spent a consderable amount of time trying to make the move to FM. Since others have done a good job of going into the detailed differences in the features, I'll talk more in broad generalities about my experiences. First, I found that FM is certainly easier to get started with than Helix. The model is common to many databases - use a dialog to define fields and their attributes, then assemble them on forms to layout entry or list views. The Helix model of each field, template, view, index, etc. being an object and icon of its own is something of a stumbling block for many new users. However, once that paradigm shift is made (I won't really call it a learning curve) the Helix model seems to me to be much more straightforward. In FM I often found myself in what I'd call "Dialog-Hell" :-) This is where you drill down though dialog after dialog only to find that the feature you are looking for is buried deep in some other dialog-path. I image that, with enough use, this becomes second nature and is not a problem. What I did find is that it is very easy to build quick flat-file databases such as the average user might use to keep track of CDs, Video tapes, etc. In fact, its so quick and easy that I used it to create a simple database for tracking bugs and features in my development efforts for Helix projects. For that kind of thing its quicker than Helix. And I know from looking at available FM solution downloads that many people use it for more powerful relational database solutions such as invoicing and accounting. However, when I tried move to FM from Helix, I found myself coming up against roadblocks as I got into the more complex constructs. It was a few years ago so I don't remember the details, but I did call FileMaker's tech support several times only to be told that "You can't do that in FM". I guess my overall impression is that, once you've learned Helix's basics, it scales up very well to be able to handle some VERY complex solutions. On the other Hand, FM is easier at the low end of the scale, but the difficulty rises rapidly as the complexity of the solution rises. Eventually, FM reaches a point where the amount of effort or work arounds required to do something, just isn't worth it. That point is reached in Helix a LOT farther along the complexity curve. Don't get me wrong, Helix has its limitations too, as others have pointed out. One of my favoite FM features that Helix does not have is the fields on list views that expand or contract depending on the contents of the fields. This allows each record to take more or less space on the view as required. But, while there are several specifics of FM that I lust for -) the bottom line is that I can create complex databases in VERY little time in Helix. Using it as a RADE environment I can create a menu/window/dialog application that looks and feels VERY much like a real application, really quickly and without writing a line of code. Its that power that has me hooked! I'm really glad to see that Helix development is back on track. I'm hoping many of the features Helix lacks will start appearing in the coming year, making Helix a real contender in the database market.