Viewing 15 posts - 55,066 through 55,080 (of 59,098 total)
I guess I'd have to say, like anything else, "It depends" ![]()
Had one recruiter try to push me into an Oracle job I didn't...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 13, 2007 at 5:45 am
Then, you can do one of two things...
1. Import to a 3 column staging table (where you can also validate the data before making it live, good safeguard) and transfer...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 13, 2007 at 5:36 am
Oh, I agree... I'm lucky enough to have a similar situation.
Just wanted everyone to know the implicit "dots" work the same way (month before day) on certain servers and not...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 13, 2007 at 5:21 am
Yeah, shame on me... I keep forgetting about that...
On other servers, particularly those outside the U.S.A., the reverse failure would be true...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 13, 2007 at 5:16 am
Jonathon
I agree with Kenneth... proper syntax calls for the column name to be followed with either a comma, an AS with an alias followed by a comma, or an alias...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 13, 2007 at 5:07 am
| My aim isn't to always at all cost post 100% conclusive close-the-case posts. I'm more interested in getting... |
--Jeff Moden
Change is inevitable... Change for the better is not.
September 13, 2007 at 4:54 am
Much better... but won't work in SQL Server 2000 which is what this forum is... ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
September 13, 2007 at 4:50 am
Heh... or just pay attention to what you're doing
Either way, a trip to the estimated execution plan probably would have shown the...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 4:56 pm
Glad it helped...
Any chance of you posting your final code?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 4:50 pm
Your solution can not work without the numbers table... at least a link would have been nice...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 4:48 pm
Steal from the "sp_" code... ![]()
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 4:41 pm
Sure... when you first create a server instance, they are not there. They only appear when something first needs them... then, they persist.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 4:40 pm
Um... be careful in that assumption... while this works...
DECLARE @SomeDate DATETIME
SET @SomeDate = '05.24.2007'
PRINT @SomeDate
...this will not...
DECLARE @SomeDate DATETIME
SET @SomeDate = '24.05.2007'
PRINT @SomeDate
...because the implicit format is understood to be mm.dd.yyyy.
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 4:39 pm
Still worth it... maybe someone else can get a leg up on things if they manage to find it...
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 4:29 pm
"Error like this object already exists?" What on Earth are you doing with the Dynamic SQL?
--Jeff Moden
Change is inevitable... Change for the better is not.
September 12, 2007 at 4:18 pm
Viewing 15 posts - 55,066 through 55,080 (of 59,098 total)