Re: Informix 7.12: Stored Procs vs Roles

The big problem with giving blanket select/update/delete/insert authority [vs. stored procedures] is that the user can use any odbc client or dbaccess, etc. to access any and all data. It is unlikely that the user will go through and update every single row with your PB client with a stored procedure, but it is very possible for that user to access via odbc and do a blanket delete/update/whatever. That's the big advantage to sp's over permissions at the table level. Rob. philcya@aol.com wrote: > [snip] > ALL access to the database must be done via >stored procedures. I am trying to convince him that action will cause >loss of productivity on the development side of the house (since PB's data >window has a good Update function) and that we could do the same thing >using Informix's ROLE ability. Every use would be granted minimal access >rights from their login and each application would then set their role for >the duration of the application session to whatever role gives them the >access rights needed. This way we could get the best of both worlds: data >integrity and faster development. >I was just wondering what others thought of this. Is there something I'm >missing that stored procs would be a better way to go? >BTW - I do know that it is possible to intercept the datawindow update in >the sqlpreview event and call a stored procedure instead. I was hoping to >avoid as much additional coding as possible! >Phil Yandel | "I believe that life is 10% what happens >Sr Application Developer | to me and 90% how I react to it." >Amercian Medical Association | - Chuck Swindoll >phil_yandel@ama-assn.org | All opinions are my own... >PhilCYa@aol.com | ...no one else wants them