>My company is trying to upsize it's database backend from Visual Foxpro to SQL server.
>
>The Foxpro backend has duplicated data, tables with 130 plus columns with 40+ index's, oh yeah the company has never produce any form of worth while data dictionary so we don't even know what certain columns represent however we do know that many of them are duplicate data columns. Normalization of data does not exist here, and these are just a few small examples of what our current production backend for our live CRM database in Foxpro.
>
>The people in my I.S. department are under the impression that SQL server 2k will perform well if we just up size the back end with out changing the table structures. I am concerned about the ramifications of this decision.
>
>My opinion is that SQL is a better back end than Foxpro any day of the week but I also am of the opinion that SQL Server is more rigid and needs to be used in it's MS suggested and documented formats. While it is also my opinion that because foxpro evolved from flat file type database systems it may lend itself in a more forgiven manner to not so normalized data structures better than SQL server.
>
>I guess my question really is; with the limited description I have provided you with of our current conversion and upsizing strategy; what would your prediction be when it comes down to the feasbility and/or over all performance of the end result of upsizing this table structure to SQL server 2k for a production Call center and CRM database being used by just short of a 1000 users at a time???

If you are using SCAN loops, or even worse DO WHILE !EOF loops, moving the data to SQL Server will not significantly increase performance. In fact, performance will decrease depending on how much your code depends on indexes for optimization of the loops.

Alternatively, if you are using SELECT statements on the VFP database, moving the data as-is to SQL Server will give a good performance boost because there will be less data moving across the network. It will require a fair amount of work to replace the tables with remote views and you will have to develop a security policy for your SQL Server database. The good news is that even with lots of indexes and no normalization, the database can be moved to SQL Server fairly easily.

All that being said, it sounds like you are stuck using a styro-cup to bail out a sinking ship. The best rememdy would be to leave the production system the way it is and devote all of your energy (and $$$) on re-developing the system properly.

** Shameless plug to follow:

P.S. I'm available for contract work!