>Hi, Josef.
>
>>I wonder what kind of database applications does not need reliability.
>>IMHO there is no such animal.
>
>The ones where high reliability costs more than the value the application produces, IMHO. That's key in choosing DBFs over an industrial-strenght database.
>
>In a small shop where having corrupted indexes, a lost memo, inconsistent data, etc, is not a big problem and going back to a day-old backup is enough, DBFs can o the job at a very low cost.
>
>In mission critical systems where stopping the application means start loosing money, any database engine pays for itself preety quickly.

You're mixing two things here, Martin:

1) a small shop...
2) your database engine pays for itself very quickly (obviously a big shop).

In any case, that is not the issue.
The issue is that KenL said that DBFs don't have RELIABILITY and SQL Server does.

He is simply wrong on this. He is marketing, not stating truths!
Nor are you stating truths. You talk of "corrupted indexes, a lost memo, inconsistent data, etc as if they are a matter of course. THEY ARE NOT!
And have you noticed that we NEVER hear (well, almost never) of problems with SQL Server data? You don't think that's because there are no problems, do you? I'm confident that we can attribute it to careful administration on the part of Microsoft to keep that kind of thing as quiet as possible. Much like Roll Royce "never let its driver down".

We are under severe attack BY OUR SUPPLIER and it really bothers me a lot that others choose to encourage that attack. There is as much legitimacy that SQL Server is unreliable as there is that DBFs are unreliable!

Jim

>
>My 2 cents,