Jean, Over the past 2 years we haven't had a single index or database corruption even though our tables are around the 1.5Gb individual size with indexes that range from 100 to 700Mb with about 130 users working 24/7.
Prior to this time of stability we had VFP 9 without SP1 and more importantly cheap Gigabit or 100Mb network cards. Changing the cards to good 3Com versions solved the index/data corruption virtually overnight and the addition of SP1 made the whole system more stable. I forget the last time a C5 error appeared. As a matter of course I do a complete reindex every other stock take which occurs bi-monthly and takes about 15 minutes. Your error is more likely than not related to hardware not software and be sure to have ALL the cache options turned off on the server. As for your rewrite in VB, well if the system barfs with VFP then it will surely do the same with VB. Client server is obviously an option (as you are aware) but VFP is an ideal candidate for this without a complete rewrite, surely. I am in the process of a conversion from real VFP tables onto SQL 2K5 at the moment and although it is not simple, it's a great deal easier than a complete rewrite. Comparative testing with C# reveals little performance increase but I must admit that I do like the "Eye Candy" you can add to c# programs with all the 3rd party components that are available. The main reason for the upgrade being the requirement for remote VPN access as well as web access eventually. Also, the question of data security from prying eyes is a lot easier with Client/Server, as is real time data backup. >From now on, specific programs that require options such as scheduling etc. will be in C# but the majority of the desktop apps will remain in VFP. I'm not a dinosaur here and accept that .Net (C#) is extremely good at some things and I really can't be bothered spending the time putting in kludgy fixes to make VFP look good - this is where I will use .NET. One thing is for sure, if you do a rewrite then you will start to find all the shortcomings of VB compared with VFP and C# and my advice would be go the C# route. C# Pro's: 1. The IDE - excellent with the "Resharper" 3rd party addon being a must 2. Speed - well impressive 3. Intellisense - much better than VFP 4. Added 3rd party add-ons. Why re-invent the wheel 5. Application/Program distribution - really easy 6. The ability to develop PDA applications 7. Availability of lots of learning resources - thank God! 8. Good fun once you get up to speed C# Cons: 1. No "with....endwith" construction 2. The .NET base library of functions is just impossible to learn 3. Learning curve, not for the language basics but for .NET 4. Quirky C# syntax 5. Data Binding - this is the fault of .NET not C# but is long winded compared with VFP 6. Just when you think you've got there another revision of the language comes out or a feature such as Linq makes an appearance - DOH! At least VFP is now a stationary target. 7. I use predominantly VS2K5 and a little VS2K8 but that is now about to be superceded, so keeping up with the "latest and greatest" becomes a pain. VFP still has a place in the toolbox though and will do so for many a year. Well I deviated a little from the main thread there but what the hell! Dave Crozier -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Geoff Flight Sent: 09 December 2008 22:39 To: 'ProFox Email List' Subject: RE: VFP index corruption We have been having indexing problems lately. In fact I was able to locate some of our weirdo problems as being indexes that actually pointed to the wrong records! Talk about disastrous! We also have large files 1-2Gb with indexes of 200Mb+. This seems to exacerbate the problem. But it has also happened ing some smaller tables. All I can tell is that because it isnt client-server and so much of the index travels down the wire that something goes wrong - regularly. We are also regularly rebuilding indexes but it is a disappointing situation. It is one thing for an index to be physically corrupted and a message telling you that; it is quite another for an index to point to the wrong record without any advice! Is this something new with SP2? I dont recall index problems being so prevalent before. I'm trying to convince my client to do a complete rewrite in VB.NET and this is one of the reasons. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean Haidar Sent: Wednesday, 10 December 2008 6:13 AM To: [email protected] Subject: Re: VFP index corruption the size of the .DBF is 1.1 gig and the cdx is 158 Mg that would be be an issue? Jean ________________________________ From: Fred Taylor <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Sent: Tuesday, December 9, 2008 1:15:22 PM Subject: Re: VFP index corruption Make sure the size of your .CDX file isn't the issue. With 29 tags and that much data in the table, you may have gone over the 2GB file limit. Fred On Tue, Dec 9, 2008 at 12:11 PM, Jean Haidar <[EMAIL PROTECTED]>wrote: > The data reside on Citrix Server and it is not eady to request changes from > the Citrix Team? > > we are rebuilding the index every few days > > If it is a bad block? don't you think this error would pop up in > another Index File or some other DBF file? > > Thanks, > Jean > > > ________________________________ > From: Michael Madigan <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Sent: Tuesday, December 9, 2008 12:57:11 PM > Subject: Re: VFP index corruption > > 1. Check the event log of the computer that holds the data to see that > there are no bad blocks or other disk problems in the event logs. > > 2. Make sure opportunistic locking is turned off on the server. > > 3. Run scan disk > > > [excessive quoting removed by server] _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
