Or...<br>You could 'verticalize' the data. A 'second table' approach, but different from misterstick, this one gives unlimited fields. The limitation here is the data types need to be similar or compatible--usually not a problem if you use a string field--if you have total control of i/o then there is little chance for bad conversions. Do like this:<br>First table (tblMain--whatever structure you have)...A second table (tblExt) with this structure (3 Fields):<br><br>tblMainKey '<---whatever key was in tblMain<br>tblextFieldname '<---Unique fieldname as data values--1 rec per field<br>tblextFieldValue '<--probably text 10 or 20, handles dates, numbers, short text.<br><br>Key is<br>tblMainKey <br>tblextFieldName<br><br>Now lets say you have 1000 fields. For *each* record in tblMain, there are *1000* records in tblExt. This is not a big space problem, since it's a narrow table (only 3 fields). It *is* workable, I've done it as an academic excercise a while back. But, as misterstick alludes, you should analyze the data a bit further. I'm not saying it's out of the realm to need that many fields--there are indeed many things that have thousands of different pieces of information to store about a single item, but often closer data model examination can prevent kludges like mine and the others.<br>--Jim