Viewing 15 posts - 54,796 through 54,810 (of 59,072 total)
GilaMonster (9/29/2007)
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 9:11 pm
Did someone say "loop"??? :blink: On a single row????? :sick:
Using a previous example where 5 decimal places are required to be padded with zeros...
DECLARE @i DECIMAL(10,5)
SET...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 9:06 pm
Sorry... temporarily lost my mind... I meant CreatedBy and CreatedOn... not "Modified". 🙂
You think it's better to store all data twice on insert?... Once "normal sized" in the original...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 8:53 pm
Thanks, Bob...
First, updating 500K or even a million rows in a single update probably isn't a problem... 20 million is a problem. If you do some testing, I think...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 4:20 pm
Hold on.... let me get my pen and write this one down in my "Why I don't let developers design views" book 😀
Why do you need a unique ID on...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 4:08 pm
It was removed because it was a really bad idea...;)
Like I said, stop trying to decrypt the whole table... encrypt the lookup criteria and do a normal join or WHERE...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 4:01 pm
Why do you think you need the extra overhead of RTRIM/LTRIM when converting Decimal to Varchar?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 3:56 pm
Heh... why sure, Remi... just look at the difficulties Steve is having trying to fix some of the problems with this "forum in a can" code that RedGate bought. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 3:54 pm
Sure... somehow they managed to save trailing spaces in NVARCHAR columns... Use DATALENGTH to check... some of the columns are defined as 100 characters wide... and even if they only...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 3:51 pm
GilaMonster (9/29/2007)
TempDB has a DBID of 2, always.
Teaching how to fish... 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 3:45 pm
noeld (9/28/2007)
... Running sp_HelpDB will allow you to figure out the DBID ...
select db_name(dbid)
Cheers,
Heh... yeah... that'll work if you know the DBID... won't help you find the DBID for...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 3:40 pm
Ninja's_RGR'us (9/29/2007)
I know this data should be kept separate from...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 3:34 pm
Phil Factor (9/11/2007)
is a popular introductory article on the technique
Well, I'll be damned... Now I know who to blame... 😀 (NOT Phil... Pop Rivet!)
I've had a bit...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 10:47 am
Hi Bob...
Just confirming... how many rows does the following update?
4) The _Change fields would be the difference between the day before and the current day for the specific type. This...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 29, 2007 at 10:03 am
In that article, the part that would work for a view looks like this...
SELECT emp_id, lname, fname, job_id,
(SELECT COUNT(*) FROM employee e2 WHERE e2.emp_id <= e.emp_id AND e2.job_id =...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 28, 2007 at 8:59 am
Viewing 15 posts - 54,796 through 54,810 (of 59,072 total)