It can do. A tab in Sage CRM can be a list or a screen each based on a sperate SQL view. You can also create compuind screens based on different blocks each based on a different view.

Personally, I'd tackle this from a SQL point of view. Having 100 columns in a table is going to be a nightmare, and you are likely to soon hit the 'Cannot create row of size......'.

Out of interest, why is it you would like them all in one table?

I don't want them all in one table, from a SQL perspective, from a CRM perspective they are all logically fields related to the entity Opportunity. Using the .Net Entity Framework, a single logical entity (or object) can have many tables - is this possible in CRM?

On our current implementation, where we have had filthy Views, we have had the dreaded Cannot create row of size 8060 bytes jazz on Leads - I don't want to get into that situation again.

Do you have access to the 'Main Entity Wizard'? It is a tool released by Sage, that does all the hard work (or most) for creating entities.

You can create child entities to the opportunity, so, it is linked, and you could spread the fields across the tables. You can then edit the views, so they are linking to the tables, and pull back the necessary columns from those tables. The child tables will have the oppo_opportunityId written to them, so the rows are easily joined to the 'parent' opportunity table.

That'd be my first thought when faced with that many columns.

I don't, as I am technically the customer (we do a lot of development in house), I will ask our partner if they can supply it to us - although saying that, even if we return all these fields in a VIEW, all that data, it will still technically be a page in SQL, so the dreaded 8060 pagesize limit could still be met. Does CRM create different views for different tabs of the primary entity?

Very true, but, if you design the screens/list etc. you can be selective with what needs to be displayed, and not simply use SELECT * for every table in question.

I think, by default, when you use the main entity wizard, all of the lists/screens are based on the table itself, rather than a view, so you can then write the views and specify which views build which lists/screens and then which of these are then used on the tabs.