Viewing 15 posts - 21,811 through 21,825 (of 59,072 total)
richardmgreen1 (1/19/2015)
This is my original code:-
select distinct
abs1.[UnitNumber]
,abs1.AccountNumber
,abs1.AdmitDateTime
,abs1.DischargeDateTime
,datediff(d,abs1.admitdatetime,abs1.dischargedatetime) as...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2015 at 12:00 pm
Briceston (1/19/2015)
What would be the correct GetDate date logic for the below...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2015 at 11:54 am
...and if it's not homework, hire a consultant for this.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2015 at 11:53 am
Be advised that the "wk" DATEPART can change depending on language settings and DATEFIRST settings. It's not considered to be a good thing to use.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2015 at 11:50 am
Daniel Forrester 123 (1/19/2015)
I found a work around which seems to trick the query optimizer into working properly by comparing the Age_Band View to other dimensions that don't seem...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2015 at 8:49 am
To add to that, you're grouping by the wrong column. You need to group by the BOX TYPE column.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2015 at 8:26 am
Two methods in the following article. For performance reasons and readability (even though the code can be a bit longer), I prefer the "CROSSTAB" method.
http://www.sqlservercentral.com/articles/T-SQL/63681/
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2015 at 8:22 am
The Windows Login still has to be present on the SQL Server or the AD Group that the login belongs to has to be present on the SQL Server.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2015 at 8:18 am
Agreed. You're going with what was given and I'm trying to read minds. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2015 at 8:15 am
Estimates aren't going to work here. You have to know how long this is going to take and you'll likely need to schedule some downtime.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2015 at 8:13 am
Mauricio_ (1/19/2015)
Yes, test is the best, I agree. The only problem is that I underestimated the size of the table, it has 3 billion rows.
That's gonna leave a mark....
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2015 at 8:09 am
Grant Fritchey (1/19/2015)
I agree that keeping it simple and using ALTER TABLE is the right answer most of the time. I also agree that you...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2015 at 7:52 am
Although Chris' code does what you want, I'm not sure it does what you actually need. Yes, it works correctly (haven't run it but looks correct). If I'm reading...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2015 at 7:41 am
How long does it take to get a return if you run the following, making the appropriate change in the FROM clause, of course?
SELECT TOP 10 *
...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2015 at 7:26 am
The clustered index is based on RowID which, ostensibly, is an ever-increasing value. That means that new data is added to the logical end of the table (the clustered...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 19, 2015 at 1:18 am
Viewing 15 posts - 21,811 through 21,825 (of 59,072 total)