Viewing 15 posts - 34,471 through 34,485 (of 59,099 total)
chetanr.jain (3/28/2011)
I would prefer Log SHipping in this case.As the primary server is in Clustering mode and Secondary server is in stand-alone mode.
If you had a SAN that would do...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 28, 2011 at 7:05 am
The total (SUM) column in the example I gave is works by day and will work across many years but I suspect you mean something different. Can you be...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 28, 2011 at 7:01 am
SQLRO (3/28/2011)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 28, 2011 at 12:34 am
I'm not sure what the question is. Create the new table and when you do inserts into it from the other tables, hardcode the 3 letters from each table....
--Jeff Moden
Change is inevitable... Change for the better is not.
March 28, 2011 at 12:26 am
waqarnaeem2 (3/28/2011)
Now i tried ,Thanks to you all
So show us what you tried. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
March 28, 2011 at 12:22 am
SQLRO (3/27/2011)
We do srhink the log but not every night. We receive the data in lots (45K to 400k) which needs to be matched with the data in this...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 28, 2011 at 12:20 am
Your narrative is great but you might want to check the first link in my signature line below to get better help in the future.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 28, 2011 at 12:14 am
Marvin Maralit (3/27/2011)
I'm having trouble on tuning this update statements.
UPDATE CASE_DETAILS_V
SET USER_DATA3= LEFT(INDUSTRYDESC,105),--INDUSTRY,
USER_DATA1= TEST_PROGRAM--TEST PROGRAM
FROM (
SELECT DISTINCT ACCTNO,CIFNO,TEST_PROGRAM,INDUSTRYDESC
FROM #TBL_HAND_OFF_TMP HAND_OFF
LEFT OUTER JOIN
(
SELECT DISTINCT T2.LTDM_CTGDESC_C TEST_PROGRAM,T1.APP_ID_C APPID
FROM VIEW_LOS_APP_TAGS T1
INNER...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 28, 2011 at 12:11 am
lukus_g (3/27/2011)
Luckily, i only ever add one row at a time... which as i type it sounds a little RBAR... but that's how i'm fed the data.
ps: love...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 28, 2011 at 12:07 am
See? I do pay attention once in a while. 😛
--Jeff Moden
Change is inevitable... Change for the better is not.
March 28, 2011 at 12:02 am
Craig Farrell (3/27/2011)
Look into the OUTPUT clause...
Isn't this an SQL Server 2000 post? 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2011 at 5:46 pm
ALZDBA (3/27/2011)
I didn't say it doesn't use model db, I said it doesn't just use model.Which is not the same as "it just doesn't use model".
Ah... my bad. Sorry,...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2011 at 5:39 pm
Let's try something similar but different. 😀
First, it's impossible to determine if what we've done will have the correct performance without a wad of test data. With that in...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2011 at 5:20 pm
David Krauus (3/26/2011)
I have made this work with some pattern matching queries in a while loop. Again, not very...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2011 at 4:49 pm
sujavani.l (3/26/2011)
User ID Date
1 01\03\2011
1 02\03\2011
1 ...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2011 at 3:30 pm
Viewing 15 posts - 34,471 through 34,485 (of 59,099 total)