Comments
Sort by recent activity
I hear what you are saying about too many icons being confusing. On the other hand foreign key columns frequently have the same name in both tables so at a quick glance they wouldn't be distinguished from candidates based only on the column names. E.g. Customer.CustomerID and CustomerAddress.CustomerID.
Possibly you could use the same paper clip image but a different overlay for each icon variation.
E.g.
1) A paper clip overlaid with a key for candidates based on a foreign key.
2) A paper clip overlaid with "N" for candidates based on matching column names.
3) A paper clip overlaid with "T" for candidates based on matching data types. / comments
I hear what you are saying about too many icons being confusing. On the other hand foreign key columns frequently have the same name in both tables so at a quick glance they wouldn't be distinguis...
Thanks Jason! / comments
Thanks Jason!
Thanks for your response Jason and I understand that you there may be difficulties that prevent this from being implemented in the near future.
What I don't understand is how the authentication and security issues would be different than the ones you've already solved for the "Cross database queries" support you added in the 3.5 release.
Synonyms are just aliases, authentication and security is still based on the underlying object they are pointing at. See code example below.
Am I missing something here?
E.g.
USE OtherDb
CREATE SYNONYM dbo.CreditCard FOR AdventureWorks.Sales.CreditCard
-- Either both of the following queries will fail or both of them will succeed based on authentication and security settings.
SELECT *
FROM CreditCard
SELECT *
FROM AdventureWorks.Sales.CreditCard
/ comments
Thanks for your response Jason and I understand that you there may be difficulties that prevent this from being implemented in the near future.
What I don't understand is how the authentication and...