Yah. Thanks for mentioning it! I should say xBase ISAMs. All ISAMs are not excused to being corrupted but the advantages of Server-based are quite significant e.g. tougher to withstand corruption when technical problem occurs, and ofcourse recovery factor.

>SNIP
>>
>>If your system is running 24 hours a day 7 days a week, you need 2 to 3 hours interruption (or longer depending on the volume of data). I think that's a common problem with ISAM databases.
>
>I rather think it's a problem because THESE (VFP) "ISAM" databases have not had the intelligence applied that other, more expensive (and that's what you pay extra for, I suppose) database systems that also are essentially "ISAM", have.
>
>Reading "Inside SQL Server 7.0" a while back made it quite clear to me that SQL Server tables are "ISAM" too as they are STORED and as they are RETRIEVED. The difference seemed to me largely that they had invented a few more gizmos that add significant value to the product as a whole.
>I just don't see calling VFP's tables "ISAM" without also calling SQL Server tables "ISAM". Your doing so suggestsa distinction that, for all intents and purposes, does not exist. What would you call SQL Server's storage/retrieval method?
>
>>
>>>
>>>>Aside from its FPT w/c vulnerable to corruption. It is not stable in handling binary data.
>>>
>>>I never encoutered problems with this. AFAIK this is not a very common problem. There a lot of potential problem causing corruption, however you can do a lot to minimize the occurance of such problems. Using data buffering solved almost all data curruption problems I ever encountered. I've got about 100 systems with a few thousand users in the field for about three years now. Until today there has not been a single report of curruption of any kind in the database.
>>
>>We have a Finger Scanning VFP application and it gives us headache because the FPT is regularly being corrupted eventhough there is no technical pc problem.
>
>OK, then why do you blame VFP's "ISAM" tables/.FPTs for this? Hell, we've had reported here, very recently, a problem where some simple external icon-manipulation software interfered drastically with VFP. We've had reports here that VFP gives C000005s when product XXXXXXX is running.
>Sure, you may have "proven" that FPT corruption is related directly to your finger scanning software, but why then extrapolate that to be a general problem with .FPTs??? Why point squarely at VFP at all?
>My applications have used MEMO fields extensively, albeit in rather simple and benign ways. I have never encountered a corrupted .FPT myself either.
>
>>
>>>Note that my statement was made on DMBSs like Oracle, SQL-server and MSDE, not on SQL-server specificly nor any of its versions. Personally I've had some headaches with MSDE. Suddenly, the database engine crashed and could not start up anymore. I tried reinstalling, examined the installation log, looked at MSDN etc, called the helpdesk, but could not solve the problem. Finally I had to reinstall Windows in order to make it work again. The conclusion I drew was that some dependency files must have been the problem.
>>
>>>One question tough, why is the SQL-server version as twice as expensive as the VFP version? Only because of purchasing SQL and licences or is there another factor?
>>
>>Merely because SQL Server is highly respected DB and it adds value to our application. With Oracle you need high caliber DB Admin but with SQL Server, the developer is enough as long as he knows what he's doing.
>
>Again, after reading "Inside SQL Server 7.0", I think you are fooling yourself with your last sentence above. If you think VFP tables take care in their design and maintenance (to achieve near-optimum performance/stability) I can say that SQL Server takes more care, more often. Not to mention the administrative issues like granting access rights, log administration, statistics review/action, etc. My guess is that surprises are around the corner if that's really how you are handling SQL Server deployments.
>
>>
>>>>Now if you want to earn a living through Retainer's FEE, then stick to VFP/VFP combination.
>>
>>VFP DB needs regular maintenance and no matter how complete your app is e.g. reindexing and packing tools, corruption is always imminent because of technical problems beyond the developer's control. And so, there must be a Monthly or Yearly Retainer's Fee which we do. Now, we would rather choose to have a stable app with stable DB than to have a retaineer's fee at all. Really, it's uncomfortable to be in the site doing file fixing at around 3 A.M.
>
>And SQL Server really gives you this, the way you describe your deployments above? I did 20 years of support in my mainframe life, and I agree about 3am calls being a pain. I had remarkably few in the biggest FPD system I was responsible for.
>
>Jim