Viewing 15 posts - 19,336 through 19,350 (of 59,098 total)
Heh... ok... without naming names.
I consulted for one company to help them with their performance problems. In the process, I ran across a table with SSN in plain text....
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2015 at 3:28 pm
Luis Cazares (10/30/2015)
I'm not sure what you mean. What would be the problem?
INSERT INTO #TempTable(StringColumn) VALUES( @StringVariable);--OR
INSERT INTO #TempTable(StringColumn) SELECT @StringVariable;
You mean other than the fact that they're both RBAR???...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2015 at 3:11 pm
We'd only be guessing without seeing the deadlock graph and the DDL for both tables including any indexes you may have on the tables. Post those and someone might...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2015 at 11:11 am
To be honest, I'd say the quote about "half full" is incorrect, at least about the implementation for Microsoft's interpretation of the Rushmore Engine (the basis of SQL Server).
--Jeff Moden
Change is inevitable... Change for the better is not.
October 31, 2015 at 10:50 am
Just another country heard from... this one returns a DATETIME datatype and works in all versions of SQL Server.
DECLARE @StartDate DATE = '01/01/2015';
SELECT DATEADD(yy,YEAR(@StartDate)-1901,'19001106');
I still like Luis'...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 30, 2015 at 6:11 pm
greenandgold52 (10/30/2015)
--Jeff Moden
Change is inevitable... Change for the better is not.
October 30, 2015 at 5:42 pm
Your result doesn't appear to match your data but a FULL JOIN (a type of OUTER join) is what you want. Like this...
SELECT m.*, o.*
FROM...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 30, 2015 at 5:40 pm
Steve Hurst (10/29/2015)
I have an entry in the system.indexes table for an index that no longer exists on the table. How can I remove this?
How have you determined that the...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 29, 2015 at 11:51 pm
Jayanth_Kurup (10/29/2015)
http://blogs.msdn.com/b/sqlcat/archive/2008/03/02/backup-more-than-1gb-per-second-using-sql2008-backup-compression.aspxInteresting read
What's "interesting" is that it would appear (I may have misread it) that they're putting the backups on the same system as the database and that would not...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 29, 2015 at 6:20 pm
SeeknFind (10/29/2015)
--Jeff Moden
Change is inevitable... Change for the better is not.
October 29, 2015 at 6:05 pm
Eric M Russell (10/29/2015)
Some audit tables are WORN (Write Once - Read Never).
Heh... appropriate, since we just got done talking about clean laundry. 😀
--Jeff Moden
Change is inevitable... Change for the better is not.
October 29, 2015 at 12:51 pm
When you do your laundry, do you wash the clean clothes or just the dirty ones?
The same holds true in databases. Typically, there are a couple of tables that...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 29, 2015 at 12:09 pm
jamesnt (10/28/2015)
Thank you to everyone who participates on this forum. Although I've been a member...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 29, 2015 at 11:55 am
Brandie Tarvin (10/29/2015)
On behalf of all the regulars who already saw this but haven't yet responded, you are welcome. It's people like you that we do this for.
Here, here! ...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 29, 2015 at 11:53 am
christophe.bernard 47659 (10/29/2015)
Hello all,thanks for all, I'm repeat perhaps 🙂 but that wonderfull to be find some help with this site ..
have a nice day
christophe
Thank you for being interested enough...
--Jeff Moden
Change is inevitable... Change for the better is not.
October 29, 2015 at 7:50 am
Viewing 15 posts - 19,336 through 19,350 (of 59,098 total)