Couldn't you solve the design problem by creating a new table (or series of tables) that contain all of the customer data in them with a customer ID s to separate out which data belongs to whom?

Then in order to NOT have to redo all of your code everywhere, couldn't you create views to replace the MSTable1, MSTable2 tables that you have today? The views would point to your new table with a where clause that only showed the data that used to be in that MSTable1 design.

By using views in this way that are simplistic, they could even be updatable (possibly with the help of "InsteadOf" triggers), so that original code trying to add data to the views would still work.

Optimal for performance, well, no; however, it would over time allow a more smooth transition to the necessary structure to eliminate this problem instead of having the daunting task of redoing all of the code at once, the DB layout is how you need it to be going forward, this avoids the 106 error, AND you have the added benefit of not having to change lots of code right away, and you can gradually take your time to slowly migrate everything over to use the new structure.

Thoughts?