Viewing 15 posts - 30,001 through 30,015 (of 59,101 total)
PaulB-TheOneAndOnly (5/14/2012)
Jeff Moden (5/10/2012)
PaulB-TheOneAndOnly (5/10/2012)
Jeff Moden (5/9/2012)
PaulB-TheOneAndOnly (5/9/2012)
If MSTR_END on WHERE clause is causing the issue replace the condition with:where TO_CHAR(MSTR_END,"DD-MON-YYYY") = ''01-JAN-1700''
IIRC, that'll make for a non-SARGable search predicate...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2012 at 7:51 pm
athens1234 (5/14/2012)
Thanks, Eugene Elutin.I just did run your sql in my original pos data. It has same result of SAS!
It works fine!!
Only while you're looking. There is no guarantee...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2012 at 7:47 pm
I have no clue how to do this but it sounds very interesting and I'd like to learn how to do this as well. The only thing I can...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2012 at 7:39 pm
sql_dba123 (5/6/2012)
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2012 at 7:23 pm
The way I'd handle it is to ask the san folks to reconfigure the TempDB LUN to Raid 1.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2012 at 7:17 pm
Crud. I really do need to learn to scroll down. Gail already answered this.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2012 at 7:11 pm
rummings (5/14/2012)
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2012 at 7:09 pm
Here's an example that serves me very well for some of the larger ETL projects I work on. Do note that you have to change "yourseverinstancenamehere" appropriately.
SELECT IDENTITY(INT,1,1)...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2012 at 6:49 pm
dndaughtery (5/14/2012)
I need to load a temp table with the result set from a sproc sort of like the following:Select into #Temp
Exec usp_LoadTemPTableSproc
How can I do this?
You can use SELECT...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2012 at 6:42 pm
Geoff A (5/14/2012)
Q1: Why were table variables introduced when temporary tables were already available?
A1: Table variables have the following advantages over temporary tables: •As mentioned in the SQL Server...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2012 at 6:38 pm
Nope... even "worse". PATINDEX.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2012 at 6:21 pm
I agree... it sounds like it very well could be deadlocks. I'd make sure to enable the correct trace flags so that the SQL Server error logs will capture...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2012 at 6:19 pm
Lynn Pettis (5/14/2012)
Jeff Moden (5/14/2012)
dan-572483 (5/14/2012)
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2012 at 6:13 pm
ScottPletcher (5/14/2012)
Adding a rowversion column to every table would indeed be huge overhead for no real gain, since it likely would never be used. Eight bytes per row...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2012 at 6:01 pm
Steve Jones - SSC Editor (5/14/2012)
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2012 at 5:57 pm
Viewing 15 posts - 30,001 through 30,015 (of 59,101 total)