Viewing 15 posts - 53,371 through 53,385 (of 59,098 total)
Until they fix it, there's a work around...
1. Put your cursor one line above the code box.
2. Click and drag to one line below the code box.
3. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 10:46 am
Heh... understood... I still kick myself for some of the things I've done to a database in past lives 😀
Wouldn't really be an extra column and no tradeoff that I...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 10:42 am
I'd still be tempted to make the formatting in a calculated column for the app so I could easily create reports like "How many emails did we send today?". ...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 10:01 am
My problem with a mega-watt satilite would be that some idiot would figure out a way to turn it into a beam weapon. ION drive? Way cool application...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 9:54 am
Always select just the columns that you need.
That goes without saying for the most part. But, again, I want to remind everyone that the OP said that Microsoft said...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 9:22 am
You bet...
Personally, what I'd rather see is a real DATETIME column and a CALCULATED column to provide the varchar version that the GUI needs. Somewhere down the line,...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 9:20 am
JohnG (12/27/2007)
Use a return (OUTPUT) parameter as it is a much cleaner solution. You're calling a procedure and not a function. In coding, procedures are...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 9:13 am
Heh... dang it... I keep forgetting this is an SQL Server 2k5 forum! Thanks John.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 9:08 am
I saw that PIVOT is much faster than doing subqueries or CASE statements to transform aggregated data to columns
Jacob, if you have an example of that and a smattering of...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 9:07 am
This needs to be run on-the-fly, by non-technical end users, maybe 5-10 times per day.
The newly-created database needs to be dropped after the routine is finished.
Why is this being done?...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 8:43 am
Oh my... we've gone from using a new function that (apparently) can't do the job, to using a Cursor...
Heh... Let's get back to the basics folks!
Consider the following PIVOT...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 8:20 am
Well said, Damon. Not are they only "Ambassadors", but "I always keep in the back of my mind that a DBA is the" first scape-goat when something goes wrong....
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 7:16 am
No problem... I absolutely agree with you... unnecessary overhead should always be avoided even if performance is ok for now... someday, the scale will change and if the code isn'tready...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 7:13 am
Heh... if you write the query right, you won't need a progress bar... it'll just be done.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 7:11 am
... and be limited to 4k bytes... 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
December 27, 2007 at 7:09 am
Viewing 15 posts - 53,371 through 53,385 (of 59,098 total)