Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Pastimes : Silicon Investor, under the hood -- Ignore unavailable to you. Want to Upgrade?

To: SI Bob who wrote (1)	12/12/2004 6:28:12 PM
From: mas_	Read Replies (1) \| Respond to of 81

In Oracle you can execute a sql string dynamically by just passing it a constructed sql statement string and calling the dynamic sql command using the string as the argument. I did Sybase in the past, which has similar origins to Sql Server, and that had a similar facility if memory serves me well so I was thinking of one generic sql procedure which executes an input search string dynamically. The bit I am not clear on is why MSSearch needs to be called. Can you not construct a table which includes the message text as the major column with the thread id,author as the primary key ? That way you can reduce searches to just a one thread table.

To: SI Bob who wrote (1)	12/12/2004 8:32:23 PM
From: TGPTNDR	Read Replies (1) \| Respond to of 81

HI Bob, Re: <But a pet peeve of mine (reading this, Dave?) is using stored procs for routines that are called relatively rarely and wouldn't run noticeably more slowly or expensively with T-SQL. It's because, to me, the tiny performance gain from making SP's for everything isn't worth the cost in my annoyance and productivity when having to scroll through hundreds of SP's to get to the one I want to edit.> LOL!! Build a batch job to select the SP out of the database into your word editor and another to save it back to the database. You are really doing things the hard way. Additionally, you should have all your SPs as individual flat files readable into the DB by a batch file. How'n the hell would you recreate a new DB without such a process? -tgp

To: SI Bob who wrote (1)	12/14/2004 8:19:13 PM
From: SI Dave	Read Replies (1) \| Respond to of 81

Wow, just found this board. >But a pet peeve of mine (reading this, Dave?) is using stored procs for routines Now, let's be fair. When I first asked about this, your stated preference was that everything be in an sproc so we could easily see dependencies. Your preference has migrated a bit, and you might note that many of my sprocs now begin with "util" so they float to the bottom of the list and are grouped together. I'll get them all there, eventually. >>I'm not sure that you can, for example pass "INNER JOIN table1 ON table2" (and keeping in mind that there could be 1 through ~4 joins) as an SP parm then do a "SELECT * from message @joinparm". If you can, it'd reduce the number of SP's needed, but I think it'd completely circumvent the query execution planner, making the SP perform no faster than the T-SQL. You can, but I doubt the execution planner can "see" it. I recently modified the message deletion sproc to build a SQL statement on the fly so it would hit the correct search table, and then EXEC the MS sproc for executing a SQL statement. I can't imagine the execution planner can pre-process that, especially since there are variables used to build the statement.