November 21, 2012 at 8:04 am
opc.three (11/20/2012)
GSquared (11/20/2012)
opc.three (11/19/2012)
GSquared (11/19/2012)
Keep in mind, with synonyms, that accessing a synonym is the same as accessing a table directly. If your security policy is to disallow accessing tables directly, then synonyms will NOT be compliant with that policy.That is not completely accurate. While it is true that a synonym's textual reference is wholesale-replaced with the object it is created for before a query is executed, a synonym still acts as any other security container in the database would in that it can be in the initial object in an ownership chain, i.e. synonyms can be used in place of allowing direct table access just like a stored procedure or view might be used.
In the context of this post in particular there is an added element due to the need to abstract tables across a database boundary and therefore it implies that DB_CHAINING be ON for both the database where the synonym resides as well as the database where the table resides, and that the login have a user in both databases however synonyms could be used to abstract the underlying tables nonetheless.
I disagree. Yes, different permissions can be granted on a synonym than on the underlying object. But there's no real point to that. If you're using actual security, like minimum-needed-permissions on a login+user, then there's no point to using synonyms as a security layer. Views can actually allow for row-level security, simply by joining to a "login permissions" table. Synonyms can't do that. Views can allow for column-level security by being defined as something other than "Select *" in the Select clause. Synonyms can't do that.
Basically, synonyms allow for name-obfuscation. That can be a very useful thing, no doubt about that. But it's not a security measure. It's a coding tool, not a security one.
If the sole purpose of views is to obscure table names, that's its own form of useless waste-of-time engineering, and it also doesn't actually enhance security at all. I've seen databases designed that way, where every table had to have a "Select *" style view defined on top of it, none with a Where clause that did anything, and application code was only allowed to access the views. This is universally done out of ignorance of actual database security, and has no functional purpose at all. It's a "we don't know what we're doing, but this makes us feel safer" type thing.
Feeling safer has its own benefits, of course. It also has major drawbacks if the safety is purely an illusion.
I am well aware of the benefits and drawbacks of using a SYNONYM versus using a VIEW. I think you have blown right past the point GSquared. The intent of the OP is Alos we have a policy to to directly access the tables in the other databases and that is why we use views (sic). A SYNONYM can give us that abstraction, as will a VIEW, because through ownership chaining we can grant select on a synonym or view to allow for access to data, however not grant any permissions to local underlying structures they refer to. I suspect that the reason for having such a policy is less about security and more about allowing the database development team wiggle-room down the line if a schema change needs to be made. In my opinion it is a noble policy and one which I would like to see more shops adopt. A view that previously referred to a single table can later be rewritten to deliver data from three tables that were the result of normalizing the original one, and INSTEAD OF triggers can be added to maintain the DML interfaces. Similarly, a synonym can be dropped and a VIEW with triggers stood up in its place to accomplish the same level of refactoring. I am confident I am not telling you anything about this technique which you did not already know, so let's not beat the horse to death. Synonyms do offer the abstraction the OP is after and you stated in a previous post that it was not possible, that's all I am saying.
Then we disagree. I think it's a feel-good-through-ignorance policy.
If you want security, refactorability, RAD, schema-agnostic coding, etc., then what you really need is a proper DAL (Data Access Layer), even if that's as simple as stored procedure calls instead of direct access to tables/views or name-obscured tables/views (that's all synonyms are).
You're right that I'm blowing past the "we just need the name obscured" piece of the post. I pointed out already that I consider that an ignorant policy. I've run into it several times before, and EVERY SINGLE TIME, it's been created as a policy out of ignorance. I've never yet seen a convincing argument that it does anything useful at all, except possibly keep ignorant managers off the DBA's back. (Educating the managers is usually easier and definitely works better, but keeping them off your back has some tiny bit of value.) I'm blowing past it in order to try to point out a better way to actually accomplish something useful, instead of promoting blissful ignorance.
You disagree. That's your right.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
November 21, 2012 at 8:48 am
GSquared (11/21/2012)
opc.three (11/20/2012)
GSquared (11/20/2012)
opc.three (11/19/2012)
GSquared (11/19/2012)
Keep in mind, with synonyms, that accessing a synonym is the same as accessing a table directly. If your security policy is to disallow accessing tables directly, then synonyms will NOT be compliant with that policy.That is not completely accurate. While it is true that a synonym's textual reference is wholesale-replaced with the object it is created for before a query is executed, a synonym still acts as any other security container in the database would in that it can be in the initial object in an ownership chain, i.e. synonyms can be used in place of allowing direct table access just like a stored procedure or view might be used.
In the context of this post in particular there is an added element due to the need to abstract tables across a database boundary and therefore it implies that DB_CHAINING be ON for both the database where the synonym resides as well as the database where the table resides, and that the login have a user in both databases however synonyms could be used to abstract the underlying tables nonetheless.
I disagree. Yes, different permissions can be granted on a synonym than on the underlying object. But there's no real point to that. If you're using actual security, like minimum-needed-permissions on a login+user, then there's no point to using synonyms as a security layer. Views can actually allow for row-level security, simply by joining to a "login permissions" table. Synonyms can't do that. Views can allow for column-level security by being defined as something other than "Select *" in the Select clause. Synonyms can't do that.
Basically, synonyms allow for name-obfuscation. That can be a very useful thing, no doubt about that. But it's not a security measure. It's a coding tool, not a security one.
If the sole purpose of views is to obscure table names, that's its own form of useless waste-of-time engineering, and it also doesn't actually enhance security at all. I've seen databases designed that way, where every table had to have a "Select *" style view defined on top of it, none with a Where clause that did anything, and application code was only allowed to access the views. This is universally done out of ignorance of actual database security, and has no functional purpose at all. It's a "we don't know what we're doing, but this makes us feel safer" type thing.
Feeling safer has its own benefits, of course. It also has major drawbacks if the safety is purely an illusion.
I am well aware of the benefits and drawbacks of using a SYNONYM versus using a VIEW. I think you have blown right past the point GSquared. The intent of the OP is Alos we have a policy to to directly access the tables in the other databases and that is why we use views (sic). A SYNONYM can give us that abstraction, as will a VIEW, because through ownership chaining we can grant select on a synonym or view to allow for access to data, however not grant any permissions to local underlying structures they refer to. I suspect that the reason for having such a policy is less about security and more about allowing the database development team wiggle-room down the line if a schema change needs to be made. In my opinion it is a noble policy and one which I would like to see more shops adopt. A view that previously referred to a single table can later be rewritten to deliver data from three tables that were the result of normalizing the original one, and INSTEAD OF triggers can be added to maintain the DML interfaces. Similarly, a synonym can be dropped and a VIEW with triggers stood up in its place to accomplish the same level of refactoring. I am confident I am not telling you anything about this technique which you did not already know, so let's not beat the horse to death. Synonyms do offer the abstraction the OP is after and you stated in a previous post that it was not possible, that's all I am saying.
Then we disagree. I think it's a feel-good-through-ignorance policy.
If you want security, refactorability, RAD, schema-agnostic coding, etc., then what you really need is a proper DAL (Data Access Layer), even if that's as simple as stored procedure calls instead of direct access to tables/views or name-obscured tables/views (that's all synonyms are).
You're right that I'm blowing past the "we just need the name obscured" piece of the post. I pointed out already that I consider that an ignorant policy. I've run into it several times before, and EVERY SINGLE TIME, it's been created as a policy out of ignorance. I've never yet seen a convincing argument that it does anything useful at all, except possibly keep ignorant managers off the DBA's back. (Educating the managers is usually easier and definitely works better, but keeping them off your back has some tiny bit of value.) I'm blowing past it in order to try to point out a better way to actually accomplish something useful, instead of promoting blissful ignorance.
You disagree. That's your right.
Feel-good-through-ignorance, what on earth are you talking about? Why are you harping on this as a security issue? I have to say, we have been on a lot of the same threads and I have read a lot of your posts so naturally I have a lot of respect for your opinion because you're a really smart guy, but on this one you are are way off the mark. If implementing cross-database ownership chaining, yes, there are concerns, but that is a discrete issue separate from what is being discussed by implementing abstraction so that data consumers cannot refer directly to tables. Please, enlighten everyone as to where you see a security issue with abstracting local table names using synonyms, views and stored procedures?
I feel bad that you have not worked with a group senior enough (managers, technicians or otherwise) where they could effectively demonstrate to you the benefits of designing and implementing a database such that it would maintain its own interface on the network, allowing us to think of a database instance as a network service considered on equal footing with a web service or a network device, independent of any data-access layer with no dependencies flowing in an outward direction towards the data consumer. For the effort of treating a database in this way we gain the ability to change a database used by many data consumers without affecting those customers, again, independently. Notice that security is not a concern when thinking about the database in these terms. Security must permeate everything we do, but it is a different aspect of the conversation from this one which I would think of more as architectural and design-driven.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
November 26, 2012 at 7:22 am
opc.three (11/21/2012)
GSquared (11/21/2012)
opc.three (11/20/2012)
GSquared (11/20/2012)
opc.three (11/19/2012)
GSquared (11/19/2012)
Keep in mind, with synonyms, that accessing a synonym is the same as accessing a table directly. If your security policy is to disallow accessing tables directly, then synonyms will NOT be compliant with that policy.That is not completely accurate. While it is true that a synonym's textual reference is wholesale-replaced with the object it is created for before a query is executed, a synonym still acts as any other security container in the database would in that it can be in the initial object in an ownership chain, i.e. synonyms can be used in place of allowing direct table access just like a stored procedure or view might be used.
In the context of this post in particular there is an added element due to the need to abstract tables across a database boundary and therefore it implies that DB_CHAINING be ON for both the database where the synonym resides as well as the database where the table resides, and that the login have a user in both databases however synonyms could be used to abstract the underlying tables nonetheless.
I disagree. Yes, different permissions can be granted on a synonym than on the underlying object. But there's no real point to that. If you're using actual security, like minimum-needed-permissions on a login+user, then there's no point to using synonyms as a security layer. Views can actually allow for row-level security, simply by joining to a "login permissions" table. Synonyms can't do that. Views can allow for column-level security by being defined as something other than "Select *" in the Select clause. Synonyms can't do that.
Basically, synonyms allow for name-obfuscation. That can be a very useful thing, no doubt about that. But it's not a security measure. It's a coding tool, not a security one.
If the sole purpose of views is to obscure table names, that's its own form of useless waste-of-time engineering, and it also doesn't actually enhance security at all. I've seen databases designed that way, where every table had to have a "Select *" style view defined on top of it, none with a Where clause that did anything, and application code was only allowed to access the views. This is universally done out of ignorance of actual database security, and has no functional purpose at all. It's a "we don't know what we're doing, but this makes us feel safer" type thing.
Feeling safer has its own benefits, of course. It also has major drawbacks if the safety is purely an illusion.
I am well aware of the benefits and drawbacks of using a SYNONYM versus using a VIEW. I think you have blown right past the point GSquared. The intent of the OP is Alos we have a policy to to directly access the tables in the other databases and that is why we use views (sic). A SYNONYM can give us that abstraction, as will a VIEW, because through ownership chaining we can grant select on a synonym or view to allow for access to data, however not grant any permissions to local underlying structures they refer to. I suspect that the reason for having such a policy is less about security and more about allowing the database development team wiggle-room down the line if a schema change needs to be made. In my opinion it is a noble policy and one which I would like to see more shops adopt. A view that previously referred to a single table can later be rewritten to deliver data from three tables that were the result of normalizing the original one, and INSTEAD OF triggers can be added to maintain the DML interfaces. Similarly, a synonym can be dropped and a VIEW with triggers stood up in its place to accomplish the same level of refactoring. I am confident I am not telling you anything about this technique which you did not already know, so let's not beat the horse to death. Synonyms do offer the abstraction the OP is after and you stated in a previous post that it was not possible, that's all I am saying.
Then we disagree. I think it's a feel-good-through-ignorance policy.
If you want security, refactorability, RAD, schema-agnostic coding, etc., then what you really need is a proper DAL (Data Access Layer), even if that's as simple as stored procedure calls instead of direct access to tables/views or name-obscured tables/views (that's all synonyms are).
You're right that I'm blowing past the "we just need the name obscured" piece of the post. I pointed out already that I consider that an ignorant policy. I've run into it several times before, and EVERY SINGLE TIME, it's been created as a policy out of ignorance. I've never yet seen a convincing argument that it does anything useful at all, except possibly keep ignorant managers off the DBA's back. (Educating the managers is usually easier and definitely works better, but keeping them off your back has some tiny bit of value.) I'm blowing past it in order to try to point out a better way to actually accomplish something useful, instead of promoting blissful ignorance.
You disagree. That's your right.
Feel-good-through-ignorance, what on earth are you talking about? Why are you harping on this as a security issue? I have to say, we have been on a lot of the same threads and I have read a lot of your posts so naturally I have a lot of respect for your opinion because you're a really smart guy, but on this one you are are way off the mark. If implementing cross-database ownership chaining, yes, there are concerns, but that is a discrete issue separate from what is being discussed by implementing abstraction so that data consumers cannot refer directly to tables. Please, enlighten everyone as to where you see a security issue with abstracting local table names using synonyms, views and stored procedures?
I feel bad that you have not worked with a group senior enough (managers, technicians or otherwise) where they could effectively demonstrate to you the benefits of designing and implementing a database such that it would maintain its own interface on the network, allowing us to think of a database instance as a network service considered on equal footing with a web service or a network device, independent of any data-access layer with no dependencies flowing in an outward direction towards the data consumer. For the effort of treating a database in this way we gain the ability to change a database used by many data consumers without affecting those customers, again, independently. Notice that security is not a concern when thinking about the database in these terms. Security must permeate everything we do, but it is a different aspect of the conversation from this one which I would think of more as architectural and design-driven.
I haven't the faintest darn clue what you're on about here.
He said they have a policy that they can't access tables directly, but use views instead. Someone else suggested using synonyms instead of views. I'm challenging "what the heck does either of those things do that has any actual value?"
Thus far, nobody has answered that question. The only answer given thus far is, "it allows moving the target object and redefining the synonym, which allows for a higher level of code to continue to access the synonym, agnostic of the target object's actual location". I pointed out that a real DAL allows for that, and a LOT more, like redefining the target object in a way that is completely invisible to application code. In short, synonyms used that way are a solution, but they're an inferior solution. They're also a completely unnecessary solution.
In many cases, they'll actually break things if you use them that way. Move a table to another server, change the synonym to point at a four-part-name instead of a three-part on the local server, and suddenly code has to deal with all the limitations of the DTC and no way around that. Have a stored procedure pull the data, and higher-level applications call the proc instead. There are ways, inside procs, to mitigate DTC impact, even to effectively eliminate it on small datasets. No way to do that with a synonym or a view. Any properly built DAL (procs or otherwise) allows that kind of functionality, but synonyms and views don't. Hence, synonyms and views are a seriously inferior solution.
I pointed out that, in my experience, every time I've run into policies like this one (no table access, only views/synonyms), it's been out of a misguided idea that it somehow adds to database security. Does that mean that's universal? Of course not! It means EXACTLY what I wrote, nothing more, nothing less.
If object-mobility is the real goal, then why not allow direct table access? If you move a table, drop a synonym in place with the same name the table had in that location, and the application won't know the difference. No need to provide a synonym for every table, just for ones that have been moved. Less work, easier to document the database (less objects), less object-name collision, minutely better performance (less schema locks), easier troubleshooting and performance tuning, and so on. Accomplishes the same thing you are advocating, but does it the easy way. This is based on the idea that tables are moved far less often than not.
Really, how many tables do you move to different databases/servers on a daily basis? Weekly? Or is it more like once or twice in the lifetime of an application, if that often?
In my experience (again, limited dataset, but it's the one I have to actually deal with), it's much more common to change table structures than to change table locations. Business needs change, and suddenly what was in 3NF for the prior needs isn't in 3NF, isn't even a complete tuple, any more. Synonyms won't help with that at all, and views frequently won't. A DAL (proc or otherwise) can allow for legacy code to continue to access the same objects/methods with no changes, while new code can take advantage of the new data definitions, without data loss, and with much less work than otherwise. Hence, again, synonyms to obscure table names are an inferior solution, if they even help at all.
So, what I'm suggesting is a serious, honest appraisal of what that policy is intended to accomplish. Most likely, a move towards n-tier/MVC, would be a much better solution, would actually do what the policy intends (instead of creating the illusion of accomplishing it). Hence, I suggest looking into that. Was that advice asked for? No. Do I still give it? Yes. I have found, much of the time, that unsolicited but well-informed advice, helps overcome Dunning-Kruger issues, as well as just plain "newbie" issues of not knowing what to ask for.
I'm not sure why you feel the need to be insulting about this. I'm offering well-intended advice, based on long experience, that I have found is almost always helpful to people who actually need the help. If that offends you, so be it.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
November 26, 2012 at 9:46 pm
You make a lot of good points which is not surprising. I do not agree with many of them but as you correctly stated that's a reserved right of mine, and naturally that's a two way street. I maintain that synonyms and views can be useful tools in abstracting a schema from data consumers. They're just tools though, with properties that may or may not fit specific needs so choose them if they prove to be useful or leave them on the sidelines if they are not. There aren't security concerns with either (that I know of, still leaving that item open if you care to comment) so for me it's strictly a decision about whether their functionality is a good fit for a given requirement.
Personally I prefer to drive all data consumers towards using stored procedures for all data access however I am not always successful. Sometimes for political reasons and sometimes for technical reasons. I have dealt with some customers where it simply was not possible, e.g. dealing with an ancient IVR system that was only capable of issuing ad hoc SQL via ODBC. Meanwhile a set of procs does not necessarily constitute a proper DAL for me. There are some things the data tier should not be asked to do that better belong in application code, e.g. certain applications of sorting, string concatenation, pagination, formatting, etc.
Regarding the non-technical aspect of this thread, you lost me in your initial post which included (in my opinion) several disparaging implications making use of the word 'ignorant' multiple times.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
November 27, 2012 at 6:40 am
opc.three (11/26/2012)
You make a lot of good points which is not surprising. I do not agree with many of them but as you correctly stated that's a reserved right of mine, and naturally that's a two way street. I maintain that synonyms and views can be useful tools in abstracting a schema from data consumers. They're just tools though, with properties that may or may not fit specific needs so choose them if they prove to be useful or leave them on the sidelines if they are not. There aren't security concerns with either (that I know of, still leaving that item open if you care to comment) so for me it's strictly a decision about whether their functionality is a good fit for a given requirement.
Absolutely. They are tremendously useful in environments that you inherit that weren't set up with a proper DAL in the first place. At least they allow SOME positive refactoring without breaking legacy code that was designed for direct table access.
Personally I prefer to drive all data consumers towards using stored procedures for all data access however I am not always successful. Sometimes for political reasons and sometimes for technical reasons. I have dealt with some customers where it simply was not possible, e.g. dealing with an ancient IVR system that was only capable of issuing ad hoc SQL via ODBC. Meanwhile a set of procs does not necessarily constitute a proper DAL for me. There are some things the data tier should not be asked to do that better belong in application code, e.g. certain applications of sorting, string concatenation, pagination, formatting, etc.
We agree completely on this. Sometimes you get to design a system from the ground up and end up with exactly what you need. Most of the time, you don't.
Regarding the non-technical aspect of this thread, you lost me in your initial post which included (in my opinion) several disparaging implications making use of the word 'ignorant' multiple times.
Appologies for that. Wasn't meaning to say you are ignorant. No insult intended, sorry if it was implied.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
December 4, 2012 at 11:20 am
GSquared (11/27/2012)
opc.three (11/26/2012)
You make a lot of good points which is not surprising. I do not agree with many of them but as you correctly stated that's a reserved right of mine, and naturally that's a two way street. I maintain that synonyms and views can be useful tools in abstracting a schema from data consumers. They're just tools though, with properties that may or may not fit specific needs so choose them if they prove to be useful or leave them on the sidelines if they are not. There aren't security concerns with either (that I know of, still leaving that item open if you care to comment) so for me it's strictly a decision about whether their functionality is a good fit for a given requirement.Absolutely. They are tremendously useful in environments that you inherit that weren't set up with a proper DAL in the first place. At least they allow SOME positive refactoring without breaking legacy code that was designed for direct table access.
Personally I prefer to drive all data consumers towards using stored procedures for all data access however I am not always successful. Sometimes for political reasons and sometimes for technical reasons. I have dealt with some customers where it simply was not possible, e.g. dealing with an ancient IVR system that was only capable of issuing ad hoc SQL via ODBC. Meanwhile a set of procs does not necessarily constitute a proper DAL for me. There are some things the data tier should not be asked to do that better belong in application code, e.g. certain applications of sorting, string concatenation, pagination, formatting, etc.
We agree completely on this. Sometimes you get to design a system from the ground up and end up with exactly what you need. Most of the time, you don't.
Regarding the non-technical aspect of this thread, you lost me in your initial post which included (in my opinion) several disparaging implications making use of the word 'ignorant' multiple times.
Appologies for that. Wasn't meaning to say you are ignorant. No insult intended, sorry if it was implied.
Sorry for the delay in responding. I just returned from vacation.
I appreciate it. I did not take it as a personal attack so no apology needed. I did however view the response as aggressive towards the ideas, and one that dismissed some of the merits of using synonyms or views (even if just passthrough views) to abstract direct table access away from data consumers, specifically ones that might also happen to be tasked with doing database development. I realize you mentioned that it was your experience and that the implementers you knew of were misguided on the security aspects which is not where I was going with it.
You asked for an example via the comment what the heck does either of those things do that has any actual value?, well I just alluded to it being related to something other than security so here it goes in context. This is not a contrived or hypothetical scenario either by the way. I have worked in two shops where a policy like this existed, and as recently as two weeks ago (I am currently in between contracts). It can work quite well as long as there are no delusions about it increasing security in and of itself.
The presumption is that a policy similar to:
No database calls shall access tables directly. Where possible only procs or functions shall access data. Where a proc or function cannot be used, views (or synonyms as of 2008) can be used.
In the two shops where a policy like this existed there was a clear and premeditated division of responsibility between 1) the application developers also tasked with producing database code to allow their apps to access data in the database and 2) the DBAs responsible for managing the schema (i.e. data modeling), loading data from the backend and tuning the database via indexing or additional data model refactoring. It basically amounted to this: developers must produce and leverage the procs or functions where possible, or use views where code modules were not possible, based on the schema the DBAs provided and the DBAs will collaborate with the app devs and review the code prior to deployment. In a scenario like this, where a code module was not an option, a view or synonym could serve the purpose of upholding the policy. Technically there would be no need for a view or synonym as you correctly pointed out, but that does not preclude any merit in employing them if it upholds the policy and creates a consistency in the workflow and division of responsibilty.
You "lost me" earlier because I recoiled at the characterization that implied that all folks implementing a policy like this are implementing it out of ignorance or solely for reasons of increasing security. It's quite possible, and was the case in both shops, that the policy makers understood that a pass-through view (e.g. one that referenced a single table and included a SELECT column-list with all columns in a table) added little value from a technical perspective. I am confident that they would also understand the same would be true for a synonym in terms of adding little value from a technical perspective although I am not sure it was ever explicitly discussed.
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
December 4, 2012 at 2:02 pm
Perhaps I missed something. Aren't views used in instances like this to protect the underlying (DB2) database from mistakes? A view needn't be any more overhead than a query unless you're joining SS tables to those views, forcing SS to download the entire view before doing any selections.
Did I miss something?
Jim
December 4, 2012 at 2:14 pm
JimS-Indy (12/4/2012)
Perhaps I missed something. Aren't views used in instances like this to protect the underlying (DB2) database from mistakes? A view needn't be any more overhead than a query unless you're joining SS tables to those views, forcing SS to download the entire view before doing any selections.Did I miss something?
I think you mean a VIEW creating what looks like a local table but that is really based on a Linked Server to access a remote table. That seems *not* to be what the original poster had in mind.
There is an ambiguity in the original post as it relates to the database name db2: http://www.sqlservercentral.com/Forums/FindPost1385711.aspx
But the original poster seems to have cleared it up, that db2 (sic) is the name of a local database, one in the same instance as dbA (sic): http://www.sqlservercentral.com/Forums/FindPost1385937.aspx
There are no special teachers of virtue, because virtue is taught by the whole community.
--Plato
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply