>Temporal splitting might yield better results and changing the granularity (years/quarters/months...) is easier to manage than with things like country of origin. The partitioning/joining logic remains the same, all that changes is a few parameters in the code module that handles it, and a few filenames known only to this module and the DBA. ;-) Temporal splitting also makes it very easy to use split criteria that are independent from the partition keying logic - you could set a new split whenever the youngest partition has grown to 700 MB, for example (to allow CD-ROM archival).
>
>Also, it works very well for phasing out data that is no longer needed. Simply unregister the tables by bumping up the StartOfTimeAsWeKnowIt value in the network master config table/.ini and wait for the last client to let go of the tables in question ...
>
>We have several such 'virtual' tables - the largest about 80 GB - and it works like a charm. However, partitioning cannot help you if a single query result approaches or exceeds the 2 GB. But if that happens then you will have probably have a number of other problems anyway. *g*

Those are good points to consider Stefan. I plan to attack this problem soon, and I will certainly propose it as such to the powers that be. Thanks for your comments.