I am surprised at all the data corruption. Since I got all of my clients on UPS systems with UPS for their servers and client computers (and routers!!) I have not experienced one case of data corruption. One of my clients has over 100 workstations.

The one thing I notice between any .NET and VFP is the ability of gettin an application up and running, not all the bells and whistles, but just enough to show the client in a RAD method ... and find out that what he just knew he wanted and demanded and was so sure about was ... not what he wanted when it was shown to him that way and then proved to him that is what he said he wanted.

Fixing it at that point, getting a VFP app to get the client to say "THATS IT!" and be as happy as he can be ... has one draw back when using it for RAD. THey are now happy with what they see! Why go further, except for adding the "bells and whistles". They don't like going form VFP RAD to C# and SQL. Oh, it is new, it is Microsoft's party line it is bla, bla but he has paid for the RAD that is almost good enough and has no desire to pay for the rest.

But if you DON'T do that sort of thing and struggle along getting to the same point in C# after showing story boards, power point presnetations and all the hand waving in the world, ... the client sees the screens he has blessed in the "demonstration of non-live screens" and you can bet the answer is the same as with the VFP RAD. "No, that is not what I said." Proof otherwise offered and he agrees. Then, he curses and is frustrated at the cost of getting to what he really menat when he said otherwise.

No, I am not an amature at digging out of the client what he really needs and really wants other than what he thinks he wants. The problem is communicating back to him in a way he will pay attention to. Not all clients are this kind of a problem. But the ones that are ... I can know from the start ... about the only thing they can be communicated with is a RAD working model. Otherwise their 'arrogance' and 'disdain for the mundane details' that make the application gets in the way. (And yes for that type I do make DRACONIAN contracts, thank you. I know what I am getting into with that sort!)

So, what we got that can whoop up a RAD with C# and SQL guts that can be used as the basis of the app like VFP and a good RAD framework could do?

I can't find anythign that comes in anywhere near as fast, easy and then easy to "beat up" to become what the client really wanted.

Any help on that one?

And please, no one say, "once you have enough experience with something elst than VFP.. ... I wrote my first FORTRASH II program in 1968, thank you. I have done all FORTRANs since FORTRAN II, C, C++, C#, Pascal, Modula, REXX, VSREXX ooREXX, Prolog, ADA, CLIPS, LISP, ALGOL, COBOL and a few I have forgotten.. oh yeah, 47 kinds of BASIC ... you name it. Nothign did as nice a RAD with data storage as VFP.

I will probably still work out a lot of my database models with VFP before I go build and burn down several SQL models. It is so much easier and faster to get a feel for the data and its interplay (and how much you should REALLY normalize it.) (No, I do not always TEXTBOOK normalize. When a few "redundant fields" are used to obviate a convoluted series of SQL quiries that make most programmers go blind trying to follow you ... I cheat.

I do like handing the project off to a young programmer who may never have my level of skill because they are not a "hacker" at heart but a good 9-5 programmer. They are so much cheaper tha a good senior systems analyst/programmer/hacker (and far less of a primadonna ... they do as they are told, mostly!)






=============================================================================

Pertti,

I use Stonefield and FoxFix but not automatically. But besides header inconsistencies and index corruption I get table corruptions too which are PITA to deal with. I have heard all the typical suggestions, make sure user does not turn of pc, etc. etc. But there are many other things that contribute to table corruption, beyond my control.

Anyway, you get my point. I like VFP as a development environment, as language, but not as a backend database.


>Dmitry:
>
>I have thousands of VFP applications running out there, and I haven't seen data corruption in a long, long time. Big part of the reason is that I use a few preventative programs (Abri Recover, Stonefield data tools, and a few programs I wrote myself) that take care of table header inconsistencies, index corruption etc. automatically.
>
>Still, I have to agree that SQL express is probably the way to go in the long run, so that you don't need to fall back on these various utilities to keep things going.
>
>
>Pertti
>
>>>I agree with you 100%. If I were to start a new project today I would not use VFP tables. SQL express is the way to go.
>>>
>>>We haven't started new projects with dbfs since 1995. All SQL Server, Cache or Oracle. But that's not an argument against dbfs: it's a reality dictated by large amounts of data needed by multiple people with decent security and reliability.
>>>
>>>Not everybody has those needs.
>>>
>>>As for SQL Express: both of us can recite the advantages that might cause people to move that way. Both of us can also recite the maintenance, implementation and hardware issues that go along with that decision. Customers can and will weigh these things up.
>>
>>Your company made a smart decision in 1995. Actually I wasn't even using VFP at that time, I only started with VFP in 1998.
>>
>>I have over 100 customers and the databases are not very large. But I spend tons of time troubleshooting data corruption. It is such a drag on my time, I can't wait to convert to SQL or MYSQL or some other more stable database. But I would love to stay with VFP for windows apps. I have already done a couple of ASP.NET apps and for that I really like .NET.