I've 2 situations involving large data tables, one is very large lookup/reference tables, which I've split logically into manageable pieces, and the other is transaction type files that grow over time. In the second case, I've split these tables into yearly tables that are named accordingly (xxxx_2009) with logic to support the convention. I didn't like having to do it, and definitely would have preferred VFP support for larger table sizes, but that wasn't an option, do I did what I had to do.
Would/should I have used table size limits as a catalyst/excuse to rush into c/s and a backend dbms, and abandon using VFP tables? No. Partly because I'm resistant to group-think and the mad rush to the Next Big Thing whether it's truly the right thing to do or not, and partly because my small business customers are happy with single workstation and LAN configurations and I'm not hearing a clamor for a c/s configuration. At the same time, I'm hedging my bets, so I have implemented c/s for several internal use applications (such as shared do-list and Prospects databases) and I'm gathering input and requirements for Android device support, which may necessitate a c/s configuration, but if so it would be a configuration choice and not a requirement for my customers. Bill _______________________________________________ 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/c72bf24447b04ec6acb4c208c1d32...@bills ** 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.
