Viewing 15 posts - 39,406 through 39,420 (of 59,072 total)
udaya_1222 (3/10/2010)
Can anyone give me a some idea to eliminate duplicate records without using sql functions and by only using transformations.
Heh... what's wrong with a little T-SQL here?
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2010 at 4:34 pm
Henry_Lee (3/10/2010)
We've had a few server crashes lately due to memory, so I'm trying to get a real good understanding of how memory works.
Setup is SS 2008 Standard, Win...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2010 at 4:32 pm
Thanks for the feedback on the fix, Joachim.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2010 at 4:28 pm
Ray K (3/10/2010)
In perusing the forums, I see many arguments for and against dynamic SQL.
I would think this qualifies as...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2010 at 4:19 pm
Welsh Corgi (3/9/2010)
Some outstanding code! 😎
Thanks, WC! 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2010 at 4:06 pm
jrgustin 30365 (3/9/2010)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2010 at 4:04 pm
Yes... multiple queries in one batch job. Sometimes you can get away with just one query... sometimes not.
At this point, I'd recommend that you post your query, the table...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2010 at 3:58 pm
I agree with that... reporting tables are typically denormalized especially when rebuilt on a regular basis.
So far as the 80 joins go, did you need all 80 joins for every...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2010 at 3:50 pm
Rome1981 (3/10/2010)
Why not implement transactional replication?
That works fine but it's a bit of a PITA to maintain compared to a SAN clone. Also, the purpose of a development server...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2010 at 6:38 am
Thanks for the correction Lynn and Paul. I messed up on that one!:blush:
--Jeff Moden
Change is inevitable... Change for the better is not.
March 10, 2010 at 6:26 am
Then, a simple INNER JOIN will find the dupes. Since it's a PK, the only 2 counts you could get is 0 or 1.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 9, 2010 at 9:00 pm
See the following:
http://www.sqlservercentral.com/Forums/Topic187917-5-1.aspx
--Jeff Moden
Change is inevitable... Change for the better is not.
March 9, 2010 at 7:54 pm
While we're waiting for a bit of readily consumable test data, I have to ask... WHY? What is the business reason that requires this type of denormalization? I...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 9, 2010 at 7:37 pm
So what constitutes a dupe in your example code? Duplicate PK's, duplicate descriptions, or the combination of both?
{edit} Sorry... I missed what you said about... "then want to compare...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 9, 2010 at 7:27 pm
A 32GB TempDB just isn't necessary IF the code is well written. You need to find out what is using that much space. Normally, it'll be a...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 9, 2010 at 7:24 pm
Viewing 15 posts - 39,406 through 39,420 (of 59,072 total)