Viewing 15 posts - 50,446 through 50,460 (of 59,099 total)
gaurava16fc (5/20/2008)
select count(datetime) from XYZ where convert(datetime,left((convert(nvarchar,datetime),11)) = '2008-05-15'
Yes, that works... but no chance of an Index SEEK. The code should be written similar to the following to allow...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 1:36 am
Actually, we still need a Create Table statement, and some data. Otherwise, we're just guessing as to what your data actually looks like.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 1:14 am
SQL King (2/7/2008)
Now, some of the data may OR may NOT change on day 2, how do I compare Day1's data with Day 2 data?
Like Matt suggested, it's not possible...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 1:12 am
I've found XML splits to be just a tad on the slow side. Take a look at the following URL.
http://www.sqlservercentral.com/articles/TSQL/62867/
Also, fairly big article on splits coming out on Wednesday.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 1:02 am
Can't be done... computed columns cannot refer to other tables.
You might be able to use a trigger to accomplish this. Why do you need to do this?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 12:57 am
David Lester (5/19/2008)
RowID Char(16) {Primary Key, Unique}
Code1 Char(6)
Code2 Char(6)
Code3 Char(6)
Code4 Char(6)
What I need to do...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 12:55 am
ntaylor (5/19/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2008 at 6:49 pm
karthikeyan (5/19/2008)
Once I repair the error in the #2 code you provided, it gives me the following...
-----------------------------------------------------
3.0
(1 row(s) affected)
...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2008 at 6:47 pm
Heh.. "Oh no"... I've earned the nickname of the code I hate the most 😛
Glad it helped, Chris.
Do keep in mind that the others are correct, though... if you have...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2008 at 6:44 pm
...or 52,000...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2008 at 6:40 pm
Only thing left is to ask Karthik if he understands how it works and why... 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2008 at 6:34 pm
In that case, it may very well be that it's remembering a "bad" plan based on a previous query. That's why I use stored procedures instead of embedded SQL...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2008 at 6:17 pm
Philip Yale (5/19/2008)
I didn't actually ask why the copy to the heap was faster. In fact, the copy takes roughly the same length of...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2008 at 6:09 pm
Michael Meierruth (5/18/2008)
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2008 at 5:58 pm
george sibbald (5/19/2008)
straight delete took 8 min 47 secs and created 4GB of tran log
crawler delete took 21:49 at batches of 100,000 (40MB of log) and 9:22...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 19, 2008 at 5:52 pm
Viewing 15 posts - 50,446 through 50,460 (of 59,099 total)