ISS_Expert
asked on
Restricting access to stored procedure
Hi All,
Here is the problem (without getting into specifics). An IT support staff runs a SQL query using SQL query analyzer, saves the output to an excel spreadsheet, which is then uploaded into a system. Since the query invovles financial transactions, there is a possibility of manipulating this file prior to upload. One solution I can think of is to create a stored procedure to which the user will have only execute access (and will not be able to view/edit it) and the output will be saved into a folder to which he will not have access. Is this possible? What kind of privileges would have to be granted? Also, if the stored procedure needs to write an excel file on the server, will the user need to use a privileged account?
Thanks
Here is the problem (without getting into specifics). An IT support staff runs a SQL query using SQL query analyzer, saves the output to an excel spreadsheet, which is then uploaded into a system. Since the query invovles financial transactions, there is a possibility of manipulating this file prior to upload. One solution I can think of is to create a stored procedure to which the user will have only execute access (and will not be able to view/edit it) and the output will be saved into a folder to which he will not have access. Is this possible? What kind of privileges would have to be granted? Also, if the stored procedure needs to write an excel file on the server, will the user need to use a privileged account?
Thanks
What you're looking to do is possible but...
> An IT support staff runs a SQL query using SQL query analyzer, saves the output to an excel spreadsheet, which is then uploaded into a system.
Is the sole purpose of the spreadsheet to upload this data into another system? If so, I would seriously consider removing the middle man from the equation.
If you absolutely cannot invoke the sp from the other system or inject the data directly to it, I would wrap the sp in a bit of code that receives the result set from the sp, then inserts into the other system.
> An IT support staff runs a SQL query using SQL query analyzer, saves the output to an excel spreadsheet, which is then uploaded into a system.
Is the sole purpose of the spreadsheet to upload this data into another system? If so, I would seriously consider removing the middle man from the equation.
If you absolutely cannot invoke the sp from the other system or inject the data directly to it, I would wrap the sp in a bit of code that receives the result set from the sp, then inserts into the other system.
ASKER
Thanks Joe for your reply.
mmr159 - yes, the sole purpose is to upload this data (batch posting) into another system. The problem is that the requirement keeps changing and so the cost and time of developing a program may exceed the benefit. Can you please suggest how to wrap the sp in a bit of code (considering that the sp could keep changing)?
Thanks.
mmr159 - yes, the sole purpose is to upload this data (batch posting) into another system. The problem is that the requirement keeps changing and so the cost and time of developing a program may exceed the benefit. Can you please suggest how to wrap the sp in a bit of code (considering that the sp could keep changing)?
Thanks.
Functionally, it will still execute the stored procedure, so there is no problem with changing requirements. You will give execute permissions to the user executing or dedicated SQL user.
The executable will take any params, either command line or a small GUI. On "Go", the code will execute the proc, process the result set and insert it into the other system.
Now, as to writing the code... that's a pretty big question. What language? Platform? What do you have experience with?
For instance, this could get you started in c#... but unless you have experience with it, compiling, etc. the learning could be a little steep.
http://www.c-sharpcorner.com/uploadfile/dclark/insoutsincs11302005072332am/insoutsincs.aspx
The executable will take any params, either command line or a small GUI. On "Go", the code will execute the proc, process the result set and insert it into the other system.
Now, as to writing the code... that's a pretty big question. What language? Platform? What do you have experience with?
For instance, this could get you started in c#... but unless you have experience with it, compiling, etc. the learning could be a little steep.
http://www.c-sharpcorner.com/uploadfile/dclark/insoutsincs11302005072332am/insoutsincs.aspx
The hidden cost of implementing, maintaining, and chasing problems with the Excel method far outweigh the cost of writing a small program such as this.
Actually, one thing that that must be discussed is the "other" system. What is it? A database? Is it SQL compliant? If yes, then we might be discussing this program for nothing. I assume not. So that leaves us with how the data gets into this system? Does it have an Excel 'import' function? Does it have other documented methods of receiving this data?
Actually, one thing that that must be discussed is the "other" system. What is it? A database? Is it SQL compliant? If yes, then we might be discussing this program for nothing. I assume not. So that leaves us with how the data gets into this system? Does it have an Excel 'import' function? Does it have other documented methods of receiving this data?
ASKER
Thanks a lot mmr159 for your reply. Both systems are running SQL server. While I agree that it the output could be directly written to the other database, I think the business wants to have the ability to view the transactions before posting (they have a maker-checker control).
For this 2 systems,
a) Is it able to reach each other directly? (either one way, or bi-directional)
b) Do you have any server which can reach both servers?
if got one "yes", then you may able to implement semi-automatic job.
(actually, it should be automatic, but since data need to review before process, then it's turn to be semi-auto)
a) Is it able to reach each other directly? (either one way, or bi-directional)
b) Do you have any server which can reach both servers?
if got one "yes", then you may able to implement semi-automatic job.
(actually, it should be automatic, but since data need to review before process, then it's turn to be semi-auto)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
If it's a "yes", then why not output result into table directly?
Anyway, for your question. Yes, you can grant execute on stored procedure to IT Support's user for them to only run it. And SQL can write file to system regardless of user, since SQL will run under either dedicate user or under system account.