We did the same. We had several old time clients who were over 1.5 gb in their transaction table. We split it putting charges in one table and non-charges in another. We believe that will buy us another 5 years.
I checked out that link someone sent for the Advantage stuff. It looks good. I especially like the tools they have. We have several thousand client installations all over the US. It will be impossible, at our current support rates, to consider setting up a DSN on each computer manually. In fact, the installation and setup is the primary reason we have not moved to SQL already. We would like to use Postgresql and have an automated way to set it up so that a current client could install an update as usual and have it automatically migrate everything from dbf to sql. Our clients have an unbelievable number of different hardware configurations. I dread to think about all the possible issues. The actual VFP (or Python) programming is not the problem as I see it - it is that manual SQL administration stuff that is the problem. Most of our clients are small offices and do not have very much IT expertise around. We need a royalty free way to do it. Our clients are not going to pay a per-seat charge and we don't want to do the accounting. Also, we need to be able to deliver a turn-key product so our users don't need to download anything or manually install anything or go through a lot of complex procedures. Probably half of our clients do not have internet access. Many are still using a modem connection to transmit their files to various payers. ----- Original Message ----- From: "Ken Kixmoeller f/h" <[email protected]> To: "ProFox Email List" <[email protected]> Sent: Friday, July 16, 2010 9:50 AM Subject: Re: Large Data Tables Kent Belan wrote: > Hello, > I have a client that has been going along great for the last 10 years. He is > now ready to explode. > > We are pushing the 2 gig limit now on the client table and he wants to add > tons more. (Anticipating flames, I say this softly...) A band-aid approach that may be expedient in your current circumstances: Stay ancient and split the offending table. Many years ago, I had an old-style Fox application (I created in FP [2?] and migrated to FP-Win, then to VFP). It had one table approaching the 2G limit. Since it was only one table, I elected to split it (vertically: fields 1-40 in table A, field 1 [PK] and 41-x in another). It didn't take too long to update the forms and reports. You might even find it just as easy to upgrade some of the data access language to SQL for SPT, or even build a data object for it. That may buy you time to upgrade the application to modern standards without holding the client back while you do. (Flame away, PFers!) Ken [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/062d01cb250b$5ffff8f0$7a00a...@w2k3s02 ** 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.
