If I create a store procedure, named test, that contains lots of different columns from many different tables.
I wanna let 20 users to get access to the data with stored procedure via excel.
My question is:
Is it possible to make the user to get access only to the store procedure, test, only? Users shall not have access to table or view. Store procedure test only. I'm using SQL server 2008 R2 standard
http://msdn.microsoft.com/en-us/library/ms188371.aspx access to the single stored procedure and no permissions to the table.
Grant EXECUTE On [SpName] To [Principal]
There is no such concept as a read permissions to a table for a stored procedure. Stored procedure permissions are separate from other objects. If a user has permission to run a stored procedure, they can run it no matter what it does, even if they don't have permission to the underlying objects
Related
Im working on an azure database just adding a couple of Stored Procedures and just making sure the program I'm building with it in .NET is all aligned properly.
I'm not going to go into the Stored Procedure itself nor the Program I'm developing because I don't believe the problem is there, I have a Development program and database which is using the exact same code and they work fine, I'm using Microsoft's SQL Server Management Studio to handle everything on the servers side.
The only difference to the current setup is that I myself scripted a bunch of the Stored procedures and a single View of a table that I did not create....(I did not create the table, but I made a view for it which is a slightly different format)
The person creating most of these databases and table is one of the database administrators I guess (not Microsoft, but an employee of the company using their services), I on the other hand am a freelance programmer and I'm guessing I have somewhat limited access to the server (limited credentials).....although it's allowing me to do more or less anything I need to do like creating SP's etc.
My current (and only problem) is a single stored procedure that runs through without an error does not update the table (the table i did not create) the Stored Procedure just inserts a couple of records and then deletes a record from the same table.......
It deletes the record just fine but for some reason the INSERT doesn't insert anything.
Again, this works fine on another Development database and the programs are sending the exact same strings but this new database just doesn't want to play along.....
Could this be a permission problem I'm having between my stored procedure and the table I did not create?
I would love to dump this onto the admin guy (and already did but he dumped it back on me haha) so I just want to be sure I'm not wasting his time....... and give him something solid to go on.
Thanks for your help Paul S.
I want to get the details of the Deleted Stored Procedures and Functions
Also i want to get the info like when it was created & removed in DB.
Please guide me.
Thanks in Advance...
You can see when procedures and functions were created by looking at the CREATE_TIME column tables in the system catalog like SYSCAT.PROCEDURES and SYSCAT.FUNCTIONS.
You will have no way of knowing when these objects were dropped unless you enable auditing within the database (and review the audit logs to find instances of DROP PROCEDURE or DROP FUNCTION).
SQL Server 2000.
Is there any SP can list what databases are owned by a specific login(role)?
Like:
EXEC sp_xxxx 'myloginname'
I want to see a set of database names that's owned by myloginname. Thanks.
Unsure what you mean. So, how about these to point you in the right direction?
sp_helplogins - Provides information about logins and their associated users in each database
sp_helpuser - Reports information about the Microsoft users and roles in the current database
Can a non-adssys user run the system procedures?
I am developing a BizTalk WCF Adapter for Advantage that can be used and I need to browse and resolve the metadata. This is an add-in for Visual Studio, supporting .Net 2.0 or higher, that generates schemas and a binding file (wsdl). It can also generate classes that can be used in a WCF Service.
Our database has over 1000 tables, 50 views, and 50 procedures. We want to assign objects to a User ID and just return the objects belonging to the user.
Thanks,
Howard
Yes, non-adssys user can run the system procedures and use select to retrieve information from the system tables. Advantage uses a permission, and user/role based system to determine the user's access to the objects in the database. The user's permission will determine whether the procedure can be executed successfully or how much information are returned from the system tables.
This link provides the comprehensive information on the permission system in the Advantage data dictionary.
With regards to tables and views, to see the name of a table or view, the user must have at least the SELECT permission on the table a view. To modify table property such as constraint and index of a table the user must have ALTER permission to the table. For users who do not have ALTER permission to the table, those constrain objects and index objects are hidden from the them.
For stored procedures, the user must have EXECUTE permission on the procedure in order to see the name of the procedure.
The favored method for managing the permissions is to assign users to groups (roles), and grant permissions to the groups. User belonging to a group will inherit the permission from the group.
Conceptually, you might want to look at storing/retrieving the metadata from a descriptive table, then using THAT result to return your objects. You have a single point of access for all users using the ability to filter by SQL clause. Once you have the object data you can use a higher level permissioned "user" to return the objects without actually giving access to individual users. Just an idea.
Is is possible to restrict a stored proc to only SELECT from a database.
I want a stored proc which only selects data to execute correctly and a stored proc with UPDATE, CREATE, DELETE operations to return an error indicating insufficient permissions.
I am using Sybase 12.5
I think you're looking at the problem the wrong way. Essentially, once you give a user execute permission to a store procedure, they can execute that store procedure no matter what it does.
I think what you want to do is assign a "read-only" client role to your database and grant SELECT permissions as well as the execute permission on only the stored procedures that read data from the database. Add users to that role instead of granting them SELECT access on the database.
Separate writing and selecting actions to different procedures. And then allow selecting user to execute selecting procedures and writing user to execute selecting and writing procedures. This trick works pretty well with PostgreSQL.