Viewing 15 posts - 2,566 through 2,580 (of 7,636 total)
SQL commands execute on the SQL Server, so batch Inserts should not have any network traffic issues.
May 8, 2009 at 10:10 pm
OK, a couple of questions:
1) Are you using an exact solution? (sounds like you are)
2) Do you just need a yes/no answer (possible, not possible) or do you need a...
May 8, 2009 at 5:00 pm
Shawn Therrien (5/8/2009)
May 8, 2009 at 4:22 pm
It's not doubling the "ADD"'s anymore is it?
May 8, 2009 at 3:52 pm
Technically, all permissions are set ON objects, and TO principals (users, roles, etc.).
The SQL for this would be something like this:
DENY INSERT ON OBJECT::[schema].[YourTable] TO Public
Assuming I have that correct,...
May 8, 2009 at 3:50 pm
davidc (5/8/2009)
Dynamic SQL does indeed work. However, the report stored proc cannot be executed in that manner. It has too many statements.
Why do you say that? I've done reports...
May 8, 2009 at 3:39 pm
There are two basic ways to do this, both through a trigger:
1) Use the Update() function to determine if any of the column(s) was SET by the update (and optionally...
May 8, 2009 at 2:59 pm
Yes, but normally you would do this through Permissions setings on the table: I.E:, just Deny INSERT access to the table.
May 8, 2009 at 2:53 pm
"Sargable" effectively means "can be used to search via an index". The general rule being that a column wrapped in a function is not sargable (there are some exceptions...
May 8, 2009 at 2:40 pm
Hmmm, actually. now I am not sure that my compile-time/run-time binding explanation was correct. However, I still do think that dynamic SQL would work.
May 8, 2009 at 2:31 pm
Thanks for the correction, Gail. Hmm, does make me think that I might have gotten a couple of other things wrong today too... 🙁
May 8, 2009 at 2:23 pm
The problem is that for the most part, objects get bound at compile-time, not run-time. True #temp tables get some kind of workaround for that, but a table like...
May 8, 2009 at 2:12 pm
Frequently an APPLY can be as fast as a JOIN, however, there are many times when it will not be. It is very rare that an APPLY is ever...
May 8, 2009 at 2:04 pm
GilaMonster (5/8/2009)
RBarryYoung (5/7/2009)
May 8, 2009 at 1:35 pm
Actually, I'm more in the ambivalent camp myself. I doubt that I use either one enough in stored procedures for the performance difference to ever really matter, and if...
May 8, 2009 at 1:21 pm
Viewing 15 posts - 2,566 through 2,580 (of 7,636 total)