DASILBE
asked on
Access ADP form not seemingly effected by SQL Server 2005 Security Settings
Hello Experts,
I have successfully created a stored procedure which allows me to deny delete, insert and update privileges to a user in an SQL Server 2005 database called ACT. The procedure works fine and returns no errors when executed with the proper parameters. My problem is that although I am the creator of the database and the database owner, I want to make sure that my table is read only after my stored procedure executes. Even the owner or administrator should not be able to change the table unless another Grant is given. This procedure does not seem to be doing the job and it has no effect on the Access ADP file that is running as the front end for the database. I'm simply trying to make my table "Achievable" after the user decides to Lock the table by pressing a button on the front end. I'm not concerned with how to code this in Access, my concern is what needs to be done in SQL server to enable the change of security on the fly. Security for the SQL Server is based on login only. Thanks experts.
Dan
I have successfully created a stored procedure which allows me to deny delete, insert and update privileges to a user in an SQL Server 2005 database called ACT. The procedure works fine and returns no errors when executed with the proper parameters. My problem is that although I am the creator of the database and the database owner, I want to make sure that my table is read only after my stored procedure executes. Even the owner or administrator should not be able to change the table unless another Grant is given. This procedure does not seem to be doing the job and it has no effect on the Access ADP file that is running as the front end for the database. I'm simply trying to make my table "Achievable" after the user decides to Lock the table by pressing a button on the front end. I'm not concerned with how to code this in Access, my concern is what needs to be done in SQL server to enable the change of security on the fly. Security for the SQL Server is based on login only. Thanks experts.
Dan
USE [Act]
GO
/****** Object: StoredProcedure [dbo].[usp_DenyInsertDeleteUpdateTable] Script Date: 07/16/2009 10:48:41 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [dbo].[usp_DenyInsertDeleteUpdateTable]
(
@ARCHIVE_TABLE Char(100),
@REVIEW_YEAR Char(4),
@USER_NAME Char(50)
)
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
DECLARE @ARCHIVE_TABLE_NAME varchar(100)
DECLARE @SQL_STRING varchar(2000)
SET @ARCHIVE_TABLE_NAME = RTRIM(@ARCHIVE_TABLE) + @REVIEW_YEAR
SET @SQL_STRING = 'USE ACT; '
SET @SQL_STRING = @SQL_STRING + 'DENY DELETE, INSERT, UPDATE ON OBJECT::dbo.' + @ARCHIVE_TABLE_NAME + ' TO [' + @USER_NAME + '] '
EXECUTE usp_ExecuteSQL @SQL_STRING
END
ASKER
Hi Jimpen,
As it turns out, I found the solution. The issue was the fact that my login on the server had sysadmin privledges and these privledges automatically override any object "Deny" settings that I was imposing. The real issue is that when you use Windows login authentication for your SQL Server Security (Not mixed mode) then you have to consider the user login rights and what takes precedence. I resolved this issue by creating another login that only had "public" as user role on the SQL Server itself and the Windows login. The ADP actually integrates nicely with SQL Server. I think most of us that experience this problem just don't realize how tightly SQL server database security is tied into Windows security and which rights have precedence. The server apparently does.
As it turns out, I found the solution. The issue was the fact that my login on the server had sysadmin privledges and these privledges automatically override any object "Deny" settings that I was imposing. The real issue is that when you use Windows login authentication for your SQL Server Security (Not mixed mode) then you have to consider the user login rights and what takes precedence. I resolved this issue by creating another login that only had "public" as user role on the SQL Server itself and the Windows login. The ADP actually integrates nicely with SQL Server. I think most of us that experience this problem just don't realize how tightly SQL server database security is tied into Windows security and which rights have precedence. The server apparently does.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I'm glad you found an answer. If you click on the link Accept as a solution in your reply, it will close the question.
May all your days get brighter and brighter.
May all your days get brighter and brighter.
There is a whole ACT! zone
Database --> Contact Management --> ACT
https://www.experts-exchange.com/Database/Contact_Management/ACT/
You can do a Request Attention and have the zones added. But from reading these questions, it sounds like there is no way to achieve what you are trying to do with the ADP. Maybe if you use the ACTReader as referred to in the second link you can get close.
Can't login to SQL 2005 using Mixed Mode Authentication
https://www.experts-exchange.com/questions/23805406/Can't-login-to-SQL-2005-using-Mixed-Mode-Authentication.html
Enable sa login on existing sql 2005 database installation.
https://www.experts-exchange.com/questions/23382273/Enable-sa-login-on-existing-sql-2005-database-installation.html