Viewing 15 posts - 50,431 through 50,445 (of 59,091 total)
It's not done by Excel... it's done by the query. Add this to it...
WHERE ESASKSIZE > ' '
AND ESBIDSIZE > ' '
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 8:05 am
You would get 100 if you weren't also grouping by customer name and date as in your original code.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 7:28 am
If you substitute the word "table" for "database", I'd agree with that.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 7:25 am
All 3 work just fine if all you want to do is to detect that there is one or more. #3 is the fastest for this purpose. #1...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 7:21 am
No... redundant data is not necessary. Like I said, you could use a trigger to pull this off.
Just curious... why do you want to do this? What is...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 7:19 am
I believe you can limit that a bit by using the WITH (ROWLOCK) hint on the update.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 1:50 am
Yes... your code for the trigger... let's see it...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 20, 2008 at 1:45 am
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
Viewing 15 posts - 50,431 through 50,445 (of 59,091 total)