Hi John,

I certainly don't want to argue with an analysis and recommendations.

I once had a system with over 300 users (over 250 typically logged in simultaneously) with FPD 2.5/2.6 with *several* tables very near the 2 gig. limit and it ran beautifully, but it was decidedly well designed (I inherited responsibility, so not bragging here).
(This means that I don't think "an enterprise solution" is mandatory here, but I would say that if a re-engineer is to be done then it is the ideal opportunity to do so.)

But in that same system we also had an affliction of 2-5 crashes a day for a period, always related to indexes. We ultimately found the problem - a Rolls-Royce server (Tricord) had a "wiring harness problem". It was replaced by a more Volkswagen server and the problem went away immediately.
I guess my point is that you had better find/fix the problem or your replacement may well suffer the same fate.

Finally, I think you should do your best to get the staff programmer on-side. I believe that you will find it to be a smart move in the long run.

Good luck,

JimN


>The crashes have never been properly diagnosed. The consist of indexing problems and problems with table updates(manually handling transactions). The current developer attributes the problem due to network problems. Too generic to work with. I'm sure that if I ran a sys(3054) that most of the queries are partially and non-optmized. The SQL Server was thrown at the problem. I don't use the term "kludgeware" lightly, the UI is peppered with search screens that consist of grid objects that consist of every record in a 30,000 record table. GULP!!!!! I could just imagine the network traffic. The prior high priced consulting team which consisted of a 13 year veteran to FoxPro/FoxBase said in his analysis quote: "The current system is so poorly engineered and implemented that only a complete re-write with an enterprise solution in mind would suffice". I concur with his opinion, a typical recipe for disaster the 80/20 rule in reverse 80%coding - 20%planning.