Viewing 15 posts - 54,166 through 54,180 (of 59,072 total)
Ack... I forgot that the Name column in SysDatabases is of the SysName datatype which is actually NVARCHAR... cuts the capabilities of the script in half without a conversion.
Also, 8000...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2007 at 9:44 pm
More like SPAM than anything else...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2007 at 6:30 pm
Dynamic cross-tab...
http://www.sqlservercentral.com/Forums/Topic242919-8-1.aspx
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2007 at 6:26 pm
Yes... you need to write it in a "special" way... without a cursor! 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2007 at 6:18 pm
This report is accessing a history table that is constantly being written to by the application,
That would be part of the inconsistency... procs recompile when certain amounts of data...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2007 at 6:14 pm
I can't prove it, but apparently you have... I've heard that the sp_OA* procs have a "connection leak"...
Real key here is what do you think you need an sp_AO* string...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2007 at 6:08 pm
I don't see any similarity, either, except for the fact that Alicia has, again, not shown anything that she's tried (not to mention the double post).
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2007 at 6:00 pm
Ok, I'm not Jeff but I'm gonna take a shot at this anyway
First the question
WeekStart = DATEADD(dd,DATEDIFF(dd,-1,Date)/7*7,-1),
The /7*7 gives you a different number because the 7's are integers....
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2007 at 5:56 pm
Grumpy DBA (11/12/2007)
J Moden - Where in Michigan are you located? I heard about a possible opening...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2007 at 5:07 pm
Using the "code" and "/code" tags (you need to include square brackets around those words instead of the double quotes... ). Still sucks for the end user, though, because...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2007 at 5:01 pm
Thanks for the feedback on your solution, Juan...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2007 at 4:56 pm
It's not a good analogy. An unhealthy restaurant will get you sick or dead.
Heh... it's a great analogy... An unhealthy bit of code will make your database sick or...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2007 at 4:52 pm
Are they like restaurants opening without a health inspection?
I couldn't have come up with a better analogy if I tried... there are so many that are absolute rubbish when...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2007 at 7:06 am
No, no... I believe a checksum of each row would allow you to check for uniqueness across the 24 columns. Lookup CHECKSUM in BOL...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2007 at 6:31 am
Is this a separate request or added requirements to what has been done already?
... and NVL is ORACLE... the equivelant in SQL Server is ISNULL... but why would you not...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 12, 2007 at 6:26 am
Viewing 15 posts - 54,166 through 54,180 (of 59,072 total)