Features Using Parameterized SQL instead of Stored Procedures

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

Please do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.

This forum is for discussing mojoPortal development

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

You can monitor commits to the repository from this page. We also recommend developers to subscribe to email notifications in the developer forum as occasionally important things are announced.

Before posting questions here you might want to review the developer documentation.

Do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.
This thread is closed to new posts. You must sign in to post in the forums.
4/17/2014 4:06:40 PM
Gravatar
Total Posts 4

Features Using Parameterized SQL instead of Stored Procedures

Is there a list of features in mojoPortal that are utilizing direct or parameterized SQL commands instead of stored procedures to add/edit/delete data in the database (SQL implementation in particular)?

For example: it looks like the code that executes when a Blog post is deleted calls the method "mojoPortal.Data.DBBlog.DeleteAllCommentsForBlog()". This function seems to be doing direct deletes in the database against the table 'mp_BlogComments' rather than calling the available stored procedure on this table. It seems that almost all 'regular' CMS activity against an SQL database is facilitated via stored procedures - this is the first exception I've run into.

I ran across it because we have historically locked down the 'daily access' SQL user accounts that our MojoPortal sites utilize to only have a role with "Execute" permission on stored procedures - since the only time we typically see "direct" access to SQL objects is during setup/installation/upgrade (we run setup under a different SQL user account with full 'dbo' permissions). I can extend this 'daily activity' user account with the restricted permissions to have direct table 'CRUD' access to specific tables if I can identify which we need to loosen the controls around. That said,  from an access control perspective it would be preferable for everything to be consistently using either stored procedures or direct to table parameterized queries (makes our DBA happier).

 

 

 

4/18/2014 1:25:14 PM
Gravatar
Total Posts 18439

Re: Features Using Parameterized SQL instead of Stored Procedures

Hi,

I'm pretty certain that those few stray methods in the blog data layer are the only places in any MS SQL data layer that are not using stored procedures. I will fix that for the next release so that all methods consistently use stored procedures in the MS SQL data layer.

Thanks,

Joe

You must sign in to post in the forums. This thread is closed to new posts.