Viewing 15 posts - 58,411 through 58,425 (of 59,067 total)
Yep, true enough... I've made the same recommendation to others, myself. It's a great example of why you need a primary key, though...
-------------------------------------------------------------------------------------------------------------------------------
|--Compute Scalar(DEFINE: ([Expr1004]=datename(month,...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 4, 2006 at 9:05 am
Try something like this (defaults to tab delimited for Excel)...
BCP "SELECT au_fname, au_lname FROM pubs..authors ORDER BY au_lname" QUERYOUT Authors.xls -c -S"yourservername\instancename" -Uyourusername -Pyourpassword
--Jeff Moden
Change is inevitable... Change for the better is not.
February 3, 2006 at 9:26 pm
John,
I didn't take the time to convert some of my old code to your specific example but the following code is a good example of a "dynamic crosstab". Since the...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 3, 2006 at 8:26 pm
You could also embed the OSQL command in a Batch file that could provide instant gratification as to the outcome...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 3, 2006 at 8:15 pm
Sure, Dennis... having a bit of a lack of sleep going on myself, here's an example using the Northwind database...
USE NorthWind
DECLARE @Year CHAR(4)
SET @Year...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 3, 2006 at 8:11 pm
Concur... doesn't sound like the Developer ever heard of the IDENTITY property of a column. Using the IDENTITY property does have some other uses, as well... think of it as...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 3, 2006 at 5:52 pm
I just gotta remember to read the last page
... Serqiy already made a similar suggestion. Guess a concurrence never hurts though...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 2, 2006 at 6:52 pm
This will successfully convert characters in the DD/MM/YYYY format into a DateTime datatype without much fanfare...
CONVERT(DATETIME, yourstringdate, 103)
Here's an example you can try...
DECLARE @ddmmyyyyString CHAR(10)
SET...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 2, 2006 at 6:48 pm
I dunno... 6 bytes, 4 bytes, 8 bytes... for me, I'd still be tempted to use DateTime just because of all the things you can do with DateTime functions without...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 2, 2006 at 6:39 pm
I agree... BCP is a great tool especially when you learn how to use the format files. You could also try a simple OSQL call using the SELECT of your...
--Jeff Moden
Change is inevitable... Change for the better is not.
February 2, 2006 at 6:23 pm
Here, here! I second the thought!
--Jeff Moden
Change is inevitable... Change for the better is not.
February 2, 2006 at 6:16 pm
Thanks for the offer, Ken... we're all set.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 31, 2006 at 5:01 pm
Great article! And, I didn't like the Merge Into function anyway... ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2006 at 11:12 pm
Jesper, thanks for pulling me off the ceiling... you're the best.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2006 at 9:41 pm
Yep... I agree with Trigger... don't ever use @@IDENTITY because if a trigger fires and that trigger inserts into another table, @@IDENTITY will not contain the value you think it...
--Jeff Moden
Change is inevitable... Change for the better is not.
January 30, 2006 at 8:12 pm
Viewing 15 posts - 58,411 through 58,425 (of 59,067 total)