Viewing 15 posts - 42,586 through 42,600 (of 59,102 total)
Sorry... I missed something... had to take the code down from this post... I'll be back.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 4, 2009 at 8:24 am
I'll also add that you should propably get used to this because SET ANSI_PADDING OFF has been deprecated as have the "off" conditions for many ANSI settings have.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 3, 2009 at 8:46 pm
I guess I don't understand... textual datatypes are naturally "left justified" and there is no need to RPAD.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 3, 2009 at 8:44 pm
Chandu (8/3/2009)
Hi Jeff, I think pande wants the output in the following way
Thanks, Chandu... but, why can't OPs like this get the hint? We had a very simple request......
--Jeff Moden
Change is inevitable... Change for the better is not.
August 3, 2009 at 8:25 pm
Thanks Pete... My recommendation still stands... Use an IDENTITY column and have the students remember their "number". I don't know what Gaggle.net is, but let the students create their...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 3, 2009 at 8:19 pm
It's not quite that bad... with ANSI PADDING ON, VARCHAR can have trailing spaces if they've been assigned. It won't automatically pad spaces to the total width of the...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 3, 2009 at 2:59 am
jqd2001 (8/2/2009)
I do read all your guys comments and it is now hard to quote now:
(1) I am dealing with Crystal report in a closed sysetm so cannot have...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 3, 2009 at 1:36 am
I absolutely, positively would NOT write a script for it. Check Books Online for BCP.
And, I'm not 100% sure, but I believe that there's a "text server" or something...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 2, 2009 at 9:28 pm
Yep... I agree with that.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 2, 2009 at 9:22 pm
Heh... and I thought XML was supposed to make stuff easy. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 2, 2009 at 9:13 pm
I don't believe that you'd put that in the HAVING... why not just put it in the WHERE clause?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 2, 2009 at 9:09 pm
I haven't tried it, but check out the following...
http://www.softempire.com/sql-server-repair.html
... without a backup, it's gonna cost you one way or the other.
--Jeff Moden
Change is inevitable... Change for the better is not.
August 2, 2009 at 9:05 pm
I haven't actually done a measurement but I would say that a good reason NOT to do it would be performance just like doing a SELECT * causes performance problems...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 2, 2009 at 8:55 pm
From what I can see, there's no correlation between the UPDATE and the SELECT. How do the columns in the SELECT list relate to the table being updated?
--Jeff Moden
Change is inevitable... Change for the better is not.
August 2, 2009 at 8:52 pm
Your are correct... cursors are definitely not needed here. Sounds like you did a pretty good job avoiding them and your method seems good. With that in mind,...
--Jeff Moden
Change is inevitable... Change for the better is not.
August 2, 2009 at 8:47 pm
Viewing 15 posts - 42,586 through 42,600 (of 59,102 total)