Yes, I understand exactly what you are trying to explain to me, there are not duplicated columns in the table, the database is as normalized as it can be, I'm sure any of you guys could normalize it even better, but the way I see it sometimes a little "denormalization" is good, it makes it easier to
generate reports and to run queries.
anyhow I really appreciate you guys taking the time to make the situation
clearer for me.


Thanks a lot.


>No I am not talking about performance problems. SQL can handle that number of columns. BUT are you sure you NEED all these columns for ALL records in that DB? Are you sure the info in that columns is not repeted? I am talking about normalization of DB. And disk space :-) if the info is repeated why not extract that info in separete table? and have only ONE record for several fields. In main table you will have only one field (Foreign key) which shows you what record you need from another table. Just my thoughts, of course I don't know what is your design of the DB.
>
>
>
>>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.