You could do that, but it would be very difficult to coordinate the two views when adding, deleting, or updating records.

What I mean by breaking it down would be (PK=primary key):

Old table: Member
----------------
PK
LastName
FirstName
Address1
Address2
City
Territory
Country
PostalCode
Phone
Fax
Email
URL
blah blah


New Tables: Member
----------
PK
LastName
FirstName
Phone
Fax
Email
URL
blah blah

Address
-------------
PK
FK (foreign key)
Address1
Address2
City
Territory
Country
PostalCode


An additional advantage to this is that if other tables have "addresses", they could also use the same child address table (assuming truly unique PKs throughout the application).



>You advise breaking up into child tables based on perhaps function. Would it be a very bad idea to leave the table as is, but get around the 128 limit by creating two views of it so that each has no more than 128 fields?
>
>Thanks
>Cyril.
>
>
>
>>There are some ways around this, but the best advice I can give would be to take a hard look at your data model. Quite possibly some of those fields should or could be part of a 1-to-1 child table. Breaking out columns to child tables either by applying normalization or simply breaking out by domain or function will not only make your updates easier, they'll make your system much more responsive.
>>
>>>A table has 190 fields. In a view, I can replace up to 128 fields of an existing record and tableupdate(.t.) works. When I replace >128 fields the tableupdate fails with error 1864, SQL: Too many fields in UPDATE.
>>>
>>>I set sys(3055,2040) but that didn't overcome the 128 field limit.
>>>
>>>I can append a new record and change more than 128 fields without any problem. But when I move to an existing record and change >128 fields, the tableupdate fails.
>>>
>>>
>>>Is there a way to do this?
>>>
>>>TIA
>>>Cyril.