PMFJI, Luis
but I think what Victor and the others are trying to say is that with that many columns, that database can not be Normalized. If you have columns of repeat data, such as, phyical address, mailing address and Home of record, they sould be in another table with a link to the first table (This is just an example with a guess on your office title < g >).

Hope that makes cents,

Beth

>That is what I was trying to avoid, but thanks anyways, as for the number of columns in the backend, I don't think that is an issue for SQL Server, Out of 1024 columns that SQL can handle, I'm only using 245 so far, less than 25 percent of it's maximum capacity, I've been using it like that for 4 years now in a 400+ computer's network spread out in 4 different locations without any performance problems, I don't think 10 or 15 more columns will create a noticeable impact, unless you are talking about a different kind of problems that I'm not aware.
>
>Thank u very much to all for your response.
>
>
>
>
>>You're going to have to split it into two views. As for the backend - having that wide of a table is rarely a good idea.
>>
>>>Thanks Sergey, I was aware of that, what I need is a way to work around the limitation, my back end table has more than 255 and I was wondering if somebody out there had come out with a solution other that split that data
>>>in two views.
>>>
>>>
>>>>>Hello everyone, I have an application that have grown beyond the
>>>>>256 fields limitation of the remote view in VFP9, have anybody work around this problem?, any ideas other than using two views linked by a key?
>>>>
>>>>The maximum number of fields per record is 255. If any field allow null values, than limit is 254.