>>>>Sooo VFP Advanced has been around for a while now... today I noticed this:
>>>>
>>>>http://www.baiyujia.com/vfpadvanced/f_vfpa_about.asp
>>>>
>>>>Near the bottom of the page it says "Support Large Files " and " Support Large Memory" ...
>>>>
>>>>OMG did he pull off getting past the 2gig table size limit????
>>>
>>>Got an email from Chen with the following:
>>>
>>>VFP Advanced 10.1 version roadmap
>>>=================================
>>>March 2020, VFP Advanced 10.1 alpha version
>>>June 2020, VFP Advanced 10.1 beta version
>>>December 2020, VFP Advanced 10.1 release version
>>>
>>>I have worked for the 2 GB problem more than 1 year,
>>>I think it need a few months, even more than 1 year,
>>>I hope I can finish it this year.
>>
>>Ok that will be simply amazing if he can actually do that - it's my understanding that doing this was pretty much impossible. He has had it going in 64-bit for a while and squashed quite a few bugs -- I guess if anyone can pull it off it's him.
>
>To be honest, in this day and age, no-one should be using VFP for large tables anymore. I think it is a mistake to do this. Resources are better spend on improving other stuff (like GUI).
>
>Nowerdays, most VFP apps are in maintenance mode. I simply do not see much marketvalue in adding something that is clearly the domain of SQL server class RDBMS-es.
>
>Walter,

I agree it is probably not worth the effort at this point - if you have that much data in a table it really should be in something else like SQL Server. I guess the advantage to it would be that it could save you a lot of work in certain situations. Moving a DBF to SQL Server is easy enough -- but depending upon how the app was written there can be a lot of code that would need to be reworked. ... and sometimes splitting a table or archiving records can be a daunting task depending upon how things are written and designed. Still impressive if he can do it though :)