Sorry, guess I was not clear enough. All I was saying was that using synonyms ADDS options, but using synonyms does not replace using views at all.
Just one example of how synonyms would be benificial. Let's say our local server is SERVERA and we have a linked server SERVERB. Now let's say that the application for SERVERB is upgraded - and there are additional columns added to tables and views in the database we are referencing.
If you just use views on SERVERA to access tables/views on SERVERB - you have to modify those views to include the new columns. Once that has been done - then, you can modify the procedures and other code that needs access to those new columns. This also brings up the question of which additional columns need to be added - all of them or just some?
Using synonyms, we can just focus on modifying the stored procedures and code that need access to those new columns without having to worry about which columns actually need to be added to the views first.
In both cases, I would hope that we have created views to filter the data, exclude columns we don't want exposed, etc...
As for schema binding - when I try to bind to an object through a linked server I get:
Msg 2014, Level 16, State 1, Procedure MyDepartment, Line 2
Remote access is not allowed from within a schema-bound object.
When trying to schema bind to an object through a synonym:
Msg 2788, Level 16, State 1, Procedure MyDepartment, Line 2
Synonyms are invalid in a schemabound object or a constraint expression.
So - guess I can't schema bind in either case.
And yes, I think using synonyms ADDS value - and again, I am not saying that using synonyms is a replacement for using views. So, I guess we have to agree to disagree on the benifits of using synonyms.
Problems are opportunities brilliantly disguised as insurmountable obstacles.
How to post questions to get better answers faster
Managing Transaction Logs