Susan Zeller
szeller at cce.umn.edu
Tue Mar 4 17:15:00 CST 2003
Another big problem is that this is like tying the hands of the sproc. Part of the power of the sproc is its efficiency from compiling. Sprocs that execute dynamic sql do not compile. --Susan -----Original Message----- From: David McAFee (Home) [mailto:dmcafee at pacbell.net] Sent: Tuesday, March 04, 2003 4:49 PM To: dba-sqlserver at databaseadvisors.com; AccessD Subject: RE: [dba-SQLServer]Passing the SQL Setting to a stored procedure Yes, but why not build it in the back, then any changes that would need to be made, could be made in the BE (by modifying the SPROC) without a need for a FE update? There is also a security risk involved, if anyone was to ever figure out the sproc's name you could possibly send a TRUNCATE command or some other ill script (or at least that's what I was told when I wanted to do this :) ) HTH David McAfee -----Original Message----- From: dba-sqlserver-admin at databaseadvisors.com [mailto:dba-sqlserver-admin at databaseadvisors.com]On Behalf Of John W. Colby Sent: Tuesday, March 04, 2003 2:36 PM To: AccessD-SQLServer; AccessD Subject: [dba-SQLServer]Passing the SQL Setting to a stored procedure I just had a fascinating idea. I do a lot of building up of SQL Strings then executing them in A2K. Would it be possible to build a stored procedure where the parameter passed in is the SQL statement to be executed? IOW, do the same thing we do now, manually build a SQL string with the actual values of controls in where clauses etc., then pass that string to a stored procedure and have the stored procedure execute the SQL string and hand back the data? John W. Colby Colby Consulting www.ColbyConsulting.com _______________________________________________ dba-SQLServer mailing list dba-SQLServer at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/dba-sqlserver http://www.databaseadvisors.com