I am using two technologies for files with more then 2Gb
- ADO technology (not so fast as native VFP engine) but it has not 2Gb limitation with tables
- I try do separate tables - for you it will be ideal variant - one table one year and
very small programm for seeking into each table (sometimes I build cross-table with
customer's number and name of files where it has records). This way is a little bit complicated
- you show another way - over MySQL. I only heard that is very easy database engine and FoxPro
programmer can learn it very quickly. Good luck!


>We have some customers with tables approaching the 2gig size. They do not want to purge any data. They also say they will definitely not pay for SQL licenses as they have many workstations and the cost is prohibitive. I am pretty sure they would not pay even if it was not prohibitive. They will not hire any 'computer admin personnel' so I can only select something that my company can maintain with ordinary updates and phone support. Those of you who sell to the healthcare market know what I am talking about.
>
>Since we have hundreds of thousands of lines of FPD26 and VFP7 code dating back to 1988 and thousands of customers, I want something that requires the least amount of work, no royalties and is solid as a rock for databases with tables containing in excess of 15 gigs of data. I am using only local views with VFP7 at this time. We have customers using a Linux server as a file server and it works fine so we would consider that approach.
>
>I am interested in learning about databases that definitely will not work or a pain to work with. What about MySQL?