In your early posts, you sounded so sure so on top - and now I realize - you're right - everybody doesn't have your problems. I did not know it was such a sensitive issue. I don't remember calling you anything! My appologies if I did!

There are products out there to fix DBF corruption. Never happens to me! Your the first customer for those items I've spoken too! What am I doing wrong - Sometimes, in my loneliness, I secretly desire to be a DBF repair product customer!

BTW - I work work with SQL systems too - I think everyone one does!

>Terry, I'm sincerely glad to hear that nobody in the world has any reason to put their data in anything other than DBFs because of your wonderful experiences. Thanks so much for listening to my opinion also, which I offered only as that -- and also welcome yours (at least the constructive parts), BTW.
>
>Perhaps (or perhaps not) I've been around longer than you have. Or perhaps I live on the wrong side of the tracks. I *have* experienced situations where unscrupulous folks, even a son of the owner at one place, swiped data and used it either to steal business or to market other services to the same client list. I've also witnessed corrupted data and know that many others, some quite famous VFP developers in fact, also have. H*ly F*ck, there are how many products out there for the sole purpose of fixing DBF corruption? Why would they exist if it wasn't an issue (I know, a con job, right)? I'm very happy for you that you've never seen it and I hope that your luck holds out, but please don't try to tell me that nobody else has or that only "bad" Fox developers have, because that's a load of BS.
>
>So, do I make every client with whom I work go SQL/Oracle with full-blown security, etc? No. But then, I don't do much work with Mom and Pop, either. All I'm saying is that I like to offer clients who want at least modest security measures against that type of thing (plus transaction log recovery) a solution and a DBF isn't one IMO. One point that I try to make to VFP-only folks is that, once you've built a system or two with the data in SQL, it's NOT THAT TOUGH to do compared to putting the data in DBF files, even if you use VFP as the development tool, which I tend to do. Perhaps that's the sore point with me, if there is one -- why NOT put the data in SQL? Big companies typically already have licenses and Mom and Pop won't have to buy many licenses or may be able to use MSDE. If your Mom and Pops can't, I would at least advise them of the possible pitfalls of using DBFs vs. the savings -- if they were my clients. I'm not saying that *you* have to or should do that. *I* would.
>
>And OBTW, keep your name calling to yourself please -- I've never performed a "SQL/.NET con job" (whatever that is) and never will. I don't make more money by selling a solution with SQL data than I do one with VFP data, but then I guess that's because I know how to work with SQL Server and spent my own time/$ to learn it. I don't appreciate you insinuating that I have been conning people, just because I don't happen to think that VFP is the only tool in town and you apparently do. I only joined in here in hopes of making a few people think outside the Fox box. Admittedly, that's a waste of bandwidth here, so I'll stop and leave you to use the best d*mned tool for everything that anyone could ever want. Thanks.
>
>Kelly
>
>>I hope that Mom and Pop also know how to avoid p*ss*ng off that soon-to-be-ex employee who knows how to import their customer list, financial info, etc. from those DBFs into Excel (or whatever) and take it with him/her to the competitor that he's going to work for (or starting up).
>>
>>That's another SQL/.NET consultant con job. Most mom and pops don't have in house IT people, and if they did, they [the p-o'd IT guy], could steal it anyway. To most people in a business, the integreity and health of the data are important to the company. If the company does good - they will do good. I have never met a discruntled employee - well except for used to be almost VFP develpers preparing to be used to be almost .NET or SQL developers!:-)
>>
>>
>>>
>>And that they know how to make good backup copies of their data and are OK reconstructing at least the work that was done since the last backup, should they run into DBF file corruption.
>>
>>I have never has a file corruption issue - some systems out there have been humming along for almost 10 years! And they have BIG files! I must be doing something wrong.
>>
>>If you write VFP programs that have file corruption issues, please, by all means, move to .NET. Don't taint the rest of us with an inability to deliver the goods!