Viewing 15 posts - 58,366 through 58,380 (of 59,067 total)
What do I lookup to figure out how to change how the formatting is done? All I could find was the following and it wasn't very helpful...
You...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2006 at 9:19 pm
If you have a pot-wad of data, I suggest you create a sister table with a UNIQUE IGNORE DUPLICATES key on it... copy the data to the new table and...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2006 at 8:46 pm
The names and ID's of the objects are stored in the SYSOBJECTS table. The SQL for each is stored in SYSCOMMENTS and the ID in SYSCOMMENTS matches the ID in...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2006 at 8:11 pm
Yes, it would be faster to use a single file... but, then you'd also loose the granularity you need to check the creation of each stored procedure for errors...
I'm not...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2006 at 8:07 pm
You don't need to build a function for this... if you are always guaranteed to have 3 parts, then there's a function built into SQL Server... ya just gotta give...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2006 at 8:01 pm
You can use the hack, or you can use the functionality built into SQL Sever...
SELECT DATENAME(dw,GETDATE())+' '+CONVERT(CHAR(11),GETDATE(),106)
--Jeff Moden
Change is inevitable... Change for the better is not.
March 5, 2006 at 7:47 pm
Ummmm... why not just setup a standard maintenance plan from Enterprise Manager whick, I believe, will do all of that for you.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 2, 2006 at 10:40 pm
A better way to do this for the sake of performance is...
SELECT tab1.*
FROM tab1
LEFT OUTER JOIN tab2
ON tab1.Col1 = tab2.Col1
tab1.Col2 = tab2.Col2
...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 2, 2006 at 10:35 pm
Ah yes, absolutely true... I sometimes just forget about things I'm not allowed to use and, unfortunately, I work in a shop where .Net is not allowed. Don't know why...
--Jeff Moden
Change is inevitable... Change for the better is not.
March 2, 2006 at 4:59 am
Thanks Ray... that's just what I was looking for.
Dunno if ANSI allows for derived tables but I guess I'm going to find...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 28, 2006 at 8:49 am
The key is in the snippet Kenneth posted...
| e1 / e2 | p1 - s1 + s2 + max(6, s1 + p2 + 1) | max(6,... |
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2006 at 10:15 pm
Francis, I know exactly what you're going through... I just inherited yet another monster set of databases and I think among all the SQL procs, views, and udfs, there might...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2006 at 10:02 pm
If you just want your script to give you info from yesterday no matter what today is, you don't need FLOAT and you don't need to pass a date. I...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2006 at 9:22 pm
Not sure why you'd want to do that when a good maintenance plan will achieve the same result of having properly ordered and defragmented indexes. So, I have to ask,...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2006 at 9:02 pm
Verrryyyy nice, David... One of the better articles I've seen on this type of stuff. And, if someone takes the time to read it, there are all sorts of goodies...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 27, 2006 at 6:52 am
Viewing 15 posts - 58,366 through 58,380 (of 59,067 total)