Jeff, > I have some very large tables that are processed over a network. I > would like to split them into monthly tables - one table per month. > When I print reports I want to combine the months covering the data > range selected by the user. > > Has anyone built an application using this technique?
Sure, it's the only way to deal with very large tables in VFP. For one application I have 15 gigs in a thousand read-only reference tables that performs without a problem. It's basically a question of segmenting the data into truly useful chunks. You don't say the nature of your tables, but I'll guess that you're adding and changing current data, and the older stuff is basically there for reference (reporting). If this is the case, then you're really looking at a slightly different question: "what's the best way to archive data"? Before going to the bigger thought I'd like to talk about, I'll say that the answer really depends on intimate knowledge of the application, it's history and how it's evolving for the future. Certainly the availability of very large capacity storage devices is a major factor in this equation, but even so, the "how do I archive data" question persists, because big just keeps getting bigger. On this front, we're fighting two battles, first is VFP's size limit, but we're also dealing with the archiving problem, which are related to each other. An approach that factors somewhere into this equation is a time-tested generic IBM solution, which is available for Windows http://www-306.ibm.com/software/tivoli/products/storage-mgr-hsm/ What this product does is move data from high-speed, expensive front end devices to lower cost, larger capacity backend devices, such as tape. It will automatically move (and catalog) a little used database from disk to tape, and then retrieve it (e.g. from tape) when it is needed (it knows where everything is using it's catalog). This approach makes it possible to have extremely large (albeit segmented) database available for access with only a delay in getting to the older stuff. The other, more important, I think, consideration is the ongoing "(when) should I move my stand-alone VFP-centric application to Client/Server"? Moving to C/S is a strong argument, is made all the time, and you've already heard it here. I'm not going to knock C/S. Our peers, especially those with 'broad views', argue that it's a compelling case to go C/S and leave VFP either behind or relegated as a desktop front-end to the larger C/S solution. In ways, not the least of which is technical achievement, they are right. It is true that every programmer worth his/her salt wants to get and sell experience with backends. Heck, I've done it just to know that I can. The case I'll try to make is that, despite the fact that C/S is technically better, switching a VFP-centric app to C/S elevates the cost and complexity of the business proposition across the board, and as a consequence invariably sucks the small software enterprise into the Big League vortex, where competition is intense and capital eventually reigns supreme - at the expense of what's left of our spirit of small business independence. I suspect at least some people have made the jump only to realize the actual price was much greater then they bargained for. Bill > -- > Jeff _______________________________________________ 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.
