sorry for not supplying enuf info but I did state that the app was rather simple and not all that involved. The 2 dbf's simply share a field. I do reporting on the info and when I do, I run a prg that combines them together at report time so I have all the info in 1 dbf.



>Hi Tim,
>
>Getting any REQUIRED detail of ouf you is like pulling hen's teeth. JimB has tried real hard, to no avail.
>
>Also, RickB gave you two possible reasons yet your reply said "If that is the only reason...". Again no real information there.
>
>Finally you stated that you had only made a separate table to avoid adding 30 fields to the existing table. That seems to suggest that all of the fields in the second (newest) table do have a 1-to-1 relationship with the (keyof) the first table's records.
>
>But here's another thing to consider, adding to RickB's possible reasons. . .I once split up a table because:
>1) it was very "wide" already (not in field count, but in record length);
>2) it was very big already (over half-a-GIG;
>3) the widest fields comprised almost 70% of the record width;
>4) most importantly, the table was used in virtually *ALL* processing, both production and ad-hoc yet that 70% recordlenght portion was only used in some very specific month-end processing.
>
>Doing this resulted in far far faster processing on a day-to-day basis with only marginal increase in the specific month-end app.
>
>The original design had been adequate at the time, but not so later. When I proposed the change the boss said 'Oh, you mean its like pulling a trailer on your car everywhere you want to go when you only really need it on the weekend'. I thought that was a good analogy.
>
>Good luck, but you'll get much better answers if you help us out with INFORMATION first.
>
>Jim N
>
> >>Timothy,
>>>
>>>No one can tell if it is a good idea or not, because the best relational design in integrally combined with the actual business. If your two tables are Customers and Addresses the answer is one way, if it Cust1 and Cust2 then the answer is different.
>>>
>>>Hypothetically discussing Master and Second tables gives no information about what the data is, and to determine the best design it is critical to know what the data is.
>>
>>It just seems my app doesn't call for relational methods. I did it instead of adding all these new fields to my main table. It's not a real complex app really.