Viewing 15 posts - 56,206 through 56,220 (of 59,086 total)
Moving data from the main database does not shrink the space reserved for the main database... nor should you shrink it unless this is the very first time you've archived.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 8, 2007 at 5:07 am
Pretty sure that's what it means...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2007 at 6:27 pm
Maybe in SQL Server 2005... in 2000 the estimated execution plan show "something" and the actual execution plan shows absolutely nothing.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2007 at 4:47 pm
You said the query was throwing an error... probably be helpful if you posted the error message(s).
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2007 at 4:42 pm
It depends... what kind of string is it??? CSV, Fixed Field, XML, Quoted CSV, or ????
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2007 at 4:39 pm
Close... I'd check just for dupe ID_Num's first... the rest of the columns are ancillary in nature...
Or, just take out the ID_Num to see if the same person has been...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2007 at 1:38 pm
Are you looking at sp_Who2 during these times? You need to find the code or process that's grabbing resources and see if you can change it.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2007 at 6:45 am
A function call is limited to the 3 part naming convention... See Books Online.
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2007 at 6:04 am
500 COLUMNS???? ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2007 at 6:00 am
Not sure this is what you are looking for... but I don't think you find a more dramatic difference...
DECLARE @Counter INT --Just a loop counter
DECLARE @BitBucket INT --Just...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2007 at 5:50 am
Perhaps I'm doing something wrong, Joe... the T-SQL example you posted (repeated below), generates the sequence of numbers that follows that and repeats... not random at all...
CREATE TABLE...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 7, 2007 at 5:16 am
Different take... traded in a little bit of the simplicity and speed of Lynn's and Jason's methods for some flexibility so far as a programmable interval and the ability to...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2007 at 7:46 pm
I'm thinking it's a test question...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2007 at 4:56 pm
--===== If you have a table that looks like this... CREATE TABLE yourtable ( RowNum INT IDENTITY(1,1) PRIMARY KEY, SomeString VARCHAR(100) NULL ) GO --===== Add a constraint that looks like this ALTER...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2007 at 4:54 pm
Understood.... just wanted you to know that the computed column would do the same and is just about as fast (can even be indexed if the formula is deterministic)... it...
--Jeff Moden
Change is inevitable... Change for the better is not.
June 6, 2007 at 7:22 am
Viewing 15 posts - 56,206 through 56,220 (of 59,086 total)