Viewing 15 posts - 1 through 15 (of 274 total)
Thanks for the explanation, that makes sense.
December 2, 2010 at 9:15 am
I thought E was an id value and thus unique. Maybe I'm wrong there.
December 2, 2010 at 8:56 am
Barring some type of "fuzzy" update, the fastest way is probably to save your results as a temporary table, then use that table to UPDATE the original data and DELETE...
December 2, 2010 at 8:51 am
Is this a homework q?
Look at GROUP BY clause ... it will provide what you need.
November 30, 2010 at 3:29 pm
Of course if column1 and/or column2 are not char data types, you will need to change 'zzz' to something that matches their data type(s).
November 30, 2010 at 2:10 pm
Not a big deal. You can handle everything easily in a trigger:
CREATE TRIGGER trigger_name
ON table_name
AFTER UPDATE
AS
--if no rows were actually UPDATEd, exit immediately
IF @@ROWCOUNT = 0
...
November 30, 2010 at 2:07 pm
Note that you could have a script that:
1) created stored procs that did the update(s)
2) main code that ran or not ran each stored proc as needed based on column(s)...
November 30, 2010 at 12:27 pm
SQL compiles in batches. A "GO" statement will start a different batch. Sometimes you can use that to work around column-exists-or-not issues.
You can also use a stored proc...
November 30, 2010 at 12:15 pm
Actually, I think the original q dealt with duplicating the stored proc code. For that, I still think OBJECT_DEFINITION works much better than sp_helptext.
November 30, 2010 at 9:17 am
Since OBJECT_DEFINITION returns an NVARCHAR(MAX), I would expect it to be able to return up to 2G - 1 (or roughly 1 billion visible characters).
I've never had any issue with...
November 30, 2010 at 8:20 am
Michael and Lowell nailed it, that's what you need to do.
You might want to consider adding that as a computed column to the table, rather than doing it in the...
November 29, 2010 at 2:54 pm
I'd suggest using OBJECT_DEFINITION rather than the other methods mentioned.
November 29, 2010 at 10:16 am
I don't think so, unless you have extremely unselective data.
Being the clustered index, SQL can always do a seek if you provide a specific key value(s) or range.
November 24, 2010 at 12:48 pm
This is mainly relevant to non-clustered indexes, of course. ]If you specify the first column on a clus index, naturally it does not need to be selective to use...
November 24, 2010 at 11:29 am
Having a variable table would be lot more overhead too. I don't see any real gain from it.
If you need ~2K variables, you need them, just go ahead and...
November 24, 2010 at 8:05 am
Viewing 15 posts - 1 through 15 (of 274 total)