• Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
    Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.

stored proc vs inline sql

W

White Board

2[H]4U
Joined
Jan 2, 2001
Messages
2,079
the arguments for stored procs vs inline sql as i remember are security, maintainability and speed. in an effort to convert inline select sql (insert, update and delete operations were created as stored procs to begin with) to stored procs, i'm looking at a lot of work with questionable gains. here's what i'm thinking so far:

security:
stored procs truncate overflow but does not return error msg's. specific coding will have to be done for that which would be required for inline sql anyway.

single quotes cause the calling script to the sprocs to fail so they'll have to be replaced in script anyway, reducing the possibility for sql injection...

liberal permissions on tables aren't required as selects are all that are being done.

maintainability (and initial coding work):
stored procs are more difficult to debug, have limited string manipulation functions, no arrays...

stored procs are centralized but the script calling them are still scattered about and need to be hunted anyway.

inputs and outputs require both sprocs and script to be maintained.

explicitly specifying each and every parameter in a sproc is a pain

speed of execution:
without testing on my own and only going on hearsay, stored procs with dynamic clauses are no faster than inline sql.



am i wrong? am i missing something?
 
You must log in or register to reply here.
Back
Top