Viewing 15 posts - 57,181 through 57,195 (of 59,067 total)
Isn't it amazing that such a simple format is so very complex programatically speaking? Why they didn't make BCP do this a little easier, I'll never know...
This would be how...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2006 at 10:21 pm
Heh... thanks for the feedback, Phillip... I kinda figured it was something like that. Every once in a while, I'll look at one of these posts, start writing code, go...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2006 at 6:39 pm
As the two links John posted suggest, add an IDENTITY column to your table and concatenate with the string conversion of that.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2006 at 3:08 pm
Uhp... nope... don't need a temp table for this one, Phillip... and we don't need to go near INFORMATION_SCHEMA or SysObjects... and it flies even with lot's of data.
Suryah,
Thank...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2006 at 2:44 pm
I don't think the author intended it this way, but to answer your question of "So what if parts are copied from BOL"? Because...
1. Plagerism is in pretty bad form. ...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2006 at 10:34 am
You'd have to store it as a BIGINT... most phone numbers are too big for just INT. That would also guarantee numerics only.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 1, 2006 at 5:07 am
Why do you need DTS to preserve the leading 0? What are you using DTS for? Are you trying to create an "output file" of some sort? Why do you...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2006 at 4:44 pm
I agree with that! Store the phone number as a string of digits only... the other kludge that needs to be considered is are any international numbers ever going to...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2006 at 2:32 pm
Spot on especially about testing (or the general lack, there of)... thanks for the feedback.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2006 at 2:10 pm
Perfect, Mike... Thanks for the tip.
And I see what everyone is talking about, especially you and Confucius247... If you really want to get deeper, read the "Terms of Use"...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2006 at 1:52 pm
Move the COMMIT TRAN to before the SET statements OR modify the two SELECTs in the SET statements to ready uncommitted data with WITH (NOLOCK)...
A better question is, why are...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2006 at 12:09 am
SELECT STR(0.00,10,2)
SELECT STR(.00,10,2)
SELECT STR(0,10,2)
--Jeff Moden
Change is inevitable... Change for the better is not.
November 29, 2006 at 11:48 pm
Still, Remi is correct... it will affect even a system time test because of the distribution unless you know for sure that the distibution of the actual data will be...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 29, 2006 at 9:49 pm
NOW I remember why I never looked at BOL 2005 ... Microsoft pushes the .NET stuff down your throat even on simple documentation... BOL 2005 wants me to install the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 29, 2006 at 9:43 pm
Thanks for the tip... I've not seen BOL 2005 so I couldn't tell just by reading the article... I'll check it out...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 29, 2006 at 9:23 pm
Viewing 15 posts - 57,181 through 57,195 (of 59,067 total)