From ab-mi at post3.tele.dk Sat May 11 18:17:25 2013 From: ab-mi at post3.tele.dk (Asger Blond) Date: Sun, 12 May 2013 01:17:25 +0200 Subject: [dba-SQLServer] Schema names and security boundaries In-Reply-To: <2BF399FD17294D1983F5311563B88A88@abpc> References: <2BF399FD17294D1983F5311563B88A88@abpc> Message-ID: How do you use schema names in SQL Server if you want to use them as meaningful namespaces, and also intent to use them as security boundaries but don't want to grant permissions on the base tables to any other than admins? Some background: As you probably know Microsoft made an important change in SQL Server 2005 separating schema names and owner names. Prior to 2005 the schema name of an object always identified the owner of the object. For example an object named JohnDoe.Customer would imply that the owner of the object was a user named JohnDoe. You couldn't have an object with a more meaningful name prefix such as Sales.Customer unless you had a user named Sales, who would then be the owner of the object. Quite an awkward situation which for ages led to schema names not being used as intentional by the SQL standard: an identifier of meaningful groupings, i.e. of "namespaces". The net effect of SQL Server not conforming to the SQL standard was that objects most often wasn't identified by a meaningful namespace names but was just prefixed by dbo, implying that the object was owned by the standard database owner user dbo. IMO it's good practice to have all objects owned by the build-in standard database owner user named dbo. But IMO it's really bad practice to junk all objects into the same namespace. Fortunately Microsoft changed its practice in 2005 and brought the usage of object prefixes in accordance with standard SQL. From 2005 and onwards the prefix doesn't imply any ownership. You can now have an object named JohnDoe.Customer which is actually owned by DonaldJones (but normaly I would prefer to have it owned by the standard user dbo). And you can have an object named Sales.Customer which is actually not owned by a user named Sales but by a user named DonaldJones (but again normally I would prefer to have it owned by the standard user dbo). So far so good. But there's more to it: Security. Schema names can be used as security boundaries: If you grant a permission on a schema to a user or role you are granting this permission on each and every objects in the schema. Quite effective... But a NO GO if you are member of the school saying "Don't ever grant missions to tables, only grant permissions on programming objects accessing the tables (such as views, stored procedures, and functions)". I belong to this school. So - to repeat my question: How do you use schema names in SQL Server if you want to use them as meaningful namespaces, and also intent to use them as security boundaries but don't want to grant permissions on the base tables to any other than admins? My practice is: Create separate schemas for tables and user-accessible objects within each meaningful grouping of the objects. For example: Table Customer: Sales_Table.Customer (for the table and only accessible for admins) Sales.CustomerView (for a user accessible view on the Sales_Table.Customer table) Sales.CustomerProcedure (for a user accessible procedure on the Sales_Table.Customer table) Sales.CustomerFunction (for a user accessible function on the Sales_Table.Customer table) Note that this is not about naming conventions - whether to use prefixes such as vw for views, usp for procedures, and udf for functions. That's a different discussion. Here I'm only applying the names CustomerView etc. as placeholders for user-defined objects. My question is about separating user-defined object from tables using schema names. Curious to hear your votes for best practices. / Asger From stephen at bondsoftware.co.nz Mon May 13 23:40:01 2013 From: stephen at bondsoftware.co.nz (Stephen Bond) Date: Tue, 14 May 2013 16:40:01 +1200 Subject: [dba-SQLServer] Access SQL pass through query problem Message-ID: CROSS POSTED Neophyte question ... Windows 7. Access 2010. SQL Server2008R2. In my ODBC Data Source I have set up a UserDSN and a SystemDSN, pointing to the SQL back-end I'm reporting from (copy of customer's SQL back-end, on my PC). When I send the Access 2010 front end to the customer to test, the LinkedTable Manager re-links to the SQL tables OK but the PassThroughQueries fail. I checked the PassThroughQuery Properties, and the ODBC Connect String includes "ODBC;DSN=myName; ..." etc. The PTQ is coughing at the lack of resolution of 'myName'. I checked at the customer site and they don't have any UserDSN or SystemDSN set. They are relying on a DSN file. When they use the LinkedTable manager it strips my 'DSN=' from the table re-connection ... how do I cope with the same on PassThrough Queries? Stephen Bond From marklbreen at gmail.com Tue May 14 02:49:06 2013 From: marklbreen at gmail.com (Mark Breen) Date: Tue, 14 May 2013 08:49:06 +0100 Subject: [dba-SQLServer] Access SQL pass through query problem In-Reply-To: References: Message-ID: Hello Stephen, this only way I build my ODBC connections it from within Access. I think I usually use machine DSN. I simply click the builder in the connection string section of the pst and choose or create a ODBC from within Access. If I create it for the linked tables, I can simply select it from the pst, or vice versa but I always seem to have to create the odbc from within access. This method works well for me for years. Mark On 14 May 2013 05:40, Stephen Bond wrote: > CROSS POSTED > > Neophyte question ... > > Windows 7. Access 2010. SQL Server2008R2. > > In my ODBC Data Source I have set up a UserDSN and a SystemDSN, pointing > to the SQL back-end I'm reporting from (copy of customer's SQL back-end, > on my PC). > > When I send the Access 2010 front end to the customer to test, the > LinkedTable Manager re-links to the SQL tables OK but the > PassThroughQueries fail. I checked the PassThroughQuery Properties, and > the ODBC Connect String includes "ODBC;DSN=myName; ..." etc. The PTQ is > coughing at the lack of resolution of 'myName'. > > I checked at the customer site and they don't have any UserDSN or > SystemDSN set. They are relying on a DSN file. When they use the > LinkedTable manager it strips my 'DSN=' from the table re-connection ... > how do I cope with the same on PassThrough Queries? > > > Stephen Bond > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From dbdoug at gmail.com Tue May 14 09:26:49 2013 From: dbdoug at gmail.com (Doug Steele) Date: Tue, 14 May 2013 07:26:49 -0700 Subject: [dba-SQLServer] Access SQL pass through query problem In-Reply-To: References: Message-ID: You can control the connection string if you make the connection in code: http://www.accessmvp.com/DJSteele/DSNLessLinks.html Doug On Tue, May 14, 2013 at 12:49 AM, Mark Breen wrote: > Hello Stephen, > > this only way I build my ODBC connections it from within Access. I think I > usually use machine DSN. > > I simply click the builder in the connection string section of the pst and > choose or create a ODBC from within Access. If I create it for the linked > tables, I can simply select it from the pst, or vice versa but I always > seem to have to create the odbc from within access. This method works well > for me for years. > > Mark > > > > On 14 May 2013 05:40, Stephen Bond wrote: > > > CROSS POSTED > > > > Neophyte question ... > > > > Windows 7. Access 2010. SQL Server2008R2. > > > > In my ODBC Data Source I have set up a UserDSN and a SystemDSN, pointing > > to the SQL back-end I'm reporting from (copy of customer's SQL back-end, > > on my PC). > > > > When I send the Access 2010 front end to the customer to test, the > > LinkedTable Manager re-links to the SQL tables OK but the > > PassThroughQueries fail. I checked the PassThroughQuery Properties, and > > the ODBC Connect String includes "ODBC;DSN=myName; ..." etc. The PTQ is > > coughing at the lack of resolution of 'myName'. > > > > I checked at the customer site and they don't have any UserDSN or > > SystemDSN set. They are relying on a DSN file. When they use the > > LinkedTable manager it strips my 'DSN=' from the table re-connection ... > > how do I cope with the same on PassThrough Queries? > > > > > > Stephen Bond > > > > _______________________________________________ > > dba-SQLServer mailing list > > dba-SQLServer at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > http://www.databaseadvisors.com > > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > From stephen at bondsoftware.co.nz Tue May 14 16:26:48 2013 From: stephen at bondsoftware.co.nz (Stephen Bond) Date: Wed, 15 May 2013 09:26:48 +1200 Subject: [dba-SQLServer] Access SQL pass through query problem In-Reply-To: References: Message-ID: Thanks Doug, The tables at the client site re-link OK using Linked Table Manager but the Pass Through Query still has the Connection String from my development PC. I'll work my way through your document and get back if there's further questions ... Stephen Bond -----Original Message----- From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Doug Steele Sent: Wednesday, 15 May 2013 2:30 a.m. To: Stephen Subject: Re: [dba-SQLServer] Access SQL pass through query problem You can control the connection string if you make the connection in code: http://www.accessmvp.com/DJSteele/DSNLessLinks.html Doug On Tue, May 14, 2013 at 12:49 AM, Mark Breen wrote: > Hello Stephen, > > this only way I build my ODBC connections it from within Access. I think I > usually use machine DSN. > > I simply click the builder in the connection string section of the pst and > choose or create a ODBC from within Access. If I create it for the linked > tables, I can simply select it from the pst, or vice versa but I always > seem to have to create the odbc from within access. This method works well > for me for years. > > Mark > > > > On 14 May 2013 05:40, Stephen Bond wrote: > > > CROSS POSTED > > > > Neophyte question ... > > > > Windows 7. Access 2010. SQL Server2008R2. > > > > In my ODBC Data Source I have set up a UserDSN and a SystemDSN, pointing > > to the SQL back-end I'm reporting from (copy of customer's SQL back-end, > > on my PC). > > > > When I send the Access 2010 front end to the customer to test, the > > LinkedTable Manager re-links to the SQL tables OK but the > > PassThroughQueries fail. I checked the PassThroughQuery Properties, and > > the ODBC Connect String includes "ODBC;DSN=myName; ..." etc. The PTQ is > > coughing at the lack of resolution of 'myName'. > > > > I checked at the customer site and they don't have any UserDSN or > > SystemDSN set. They are relying on a DSN file. When they use the > > LinkedTable manager it strips my 'DSN=' from the table re-connection ... > > how do I cope with the same on PassThrough Queries? > > > > > > Stephen Bond > > > > _______________________________________________ > > dba-SQLServer mailing list > > dba-SQLServer at databaseadvisors.com > > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > > http://www.databaseadvisors.com > > > > > _______________________________________________ > dba-SQLServer mailing list > dba-SQLServer at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver > http://www.databaseadvisors.com > > _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com