On Fri, Jul 16, 2010 at 12:21 PM, <[email protected]> wrote: > 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. -------------------------
Only way to keep in VFP data is to Normalize! If you normalized your data could you save 5% data space or could it boost to savings to 20%? Some systems that were designed a long time ago are horrendous at data storage. From contacts lists to a customer or for carrying over unneeded data from related tables < item description in SO and AR transactions when the item's ID is all you need to get that back. If that is too much of a nightmare to redesign and keep your data still in Fox, you will have to find a new data container. Any DB you choose will have pluses and minuses over a number of areas. I won't try to persuade on what to do nor why, all up to you guys. Point I am trying to make is that as you plan to port over to a new DB, plan to not only copy over existing schema, but also implement the modern design that is better for the db you choose to go to. That manual DB admin stuff is pretty easy to do via scripting that you can run from your app at any time. Backups and God forbid restores are not tough at all. Schema changes are not nearly as easy but that is what scripts are all about. -- Stephen Russell Sr. Production Systems Programmer CIMSgts 901.246-0159 cell _______________________________________________ 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.
