[dba-SQLServer]Passing the SQL Setting to a stored procedure

Francisco H Tapia my.lists at verizon.net
Tue Mar 4 17:34:49 CST 2003


Still tho at the cost of opening your System to potentially *unsafe* calls
(ala, Unchecked buffer ;o)).  I seriously doubt that you would need hundreds
of sprocs, if you parametrize them you'd only need a few dozen... plus you'd
be saving yourself the bandwidth of sending the entire statement accross the
wire...tho it might seems small in the great scheme of things, you'd be
making your app less "chatty" and therefore less prone to network problems.


-Francisco
http://rcm.netfirms.com
----- Original Message -----
From: "John W. Colby" <jcolby at colbyconsulting.com>
To: <dba-sqlserver at databaseadvisors.com>
Sent: Tuesday, March 04, 2003 3:25 PM
Subject: RE: [dba-SQLServer]Passing the SQL Setting to a stored procedure


: But what I am reading is that if you are talking about a situation like I
am
: discussing, where the filter changes every time the sproc is used, the
: compile is actually counterproductive.
:
: John W. Colby
: Colby Consulting
: www.ColbyConsulting.com
:
:
: I've stopped 9,258 spam messages. You can too!
: Get your free, safe spam protection at
http://www.cloudmark.com/spamnetsig/
:
: -----Original Message-----
: From: dba-sqlserver-admin at databaseadvisors.com
: [mailto:dba-sqlserver-admin at databaseadvisors.com]On Behalf Of Susan
: Zeller
: Sent: Tuesday, March 04, 2003 6:15 PM
: To: dba-sqlserver at databaseadvisors.com
: Subject: RE: [dba-SQLServer]Passing the SQL Setting to a stored
: procedure
:
:
: 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
:
: _______________________________________________
: dba-SQLServer mailing list
: dba-SQLServer at databaseadvisors.com
: http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
: http://www.databaseadvisors.com
:
:
:
:
: ----------------------------------------------------
: Is email taking over your day?  Manage your time with eMailBoss.
: Try it free!  http://www.eMailBoss.com
:





More information about the dba-SQLServer mailing list