Viewing 15 posts - 53,986 through 54,000 (of 59,072 total)
The code I posted extracts all three fields even for the "01" records...
You didn't even try the code, did you?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 23, 2007 at 11:12 am
Why are you still fighting this problem, Ray? I gave you an answer and code that resolves all of these problems last night...
http://www.sqlservercentral.com/Forums/Topic425054-149-1.aspx#bm425122
--Jeff Moden
Change is inevitable... Change for the better is not.
November 23, 2007 at 11:10 am
Heh... good point, Brian. And, (I forget who said it) sometimes you must unlearn what you have learnt in order to find and fix a problem.
But, I believe the...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 23, 2007 at 11:05 am
Heh... and there's another good example... words like "spelt" and "learnt" may be good and proper words in "European English"... it the U.S.A., they are more correctly written and pronounced...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 23, 2007 at 4:59 am
DATETIME is really a FLOAT in the background (although it is a "fixed point float", if you can imagine that). DATETIME uses the same BINARY math as FLOAT.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 23, 2007 at 4:47 am
Sounds like some of the other "Senior Software Engineers" I've interviewed... and rejected :Whistling:
--Jeff Moden
Change is inevitable... Change for the better is not.
November 23, 2007 at 1:05 am
Haven't tried it in a view before... you must either create a Linked Server or use OPENROWSET or OPENDATASOURCE.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 22, 2007 at 9:37 pm
sp_ExecuteSQL is not an "extended stored procedure" or it would begin with "xp_". Neither is any form of dynamic SQL. I'm afraid that you're out of luck.
In fact,...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 22, 2007 at 9:33 pm
Sorry... missed the "MonetaryValue" column that you included in your code but not in your problem definition... this will do it...
SELECT s.RowID,
...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 22, 2007 at 9:23 pm
Output should be:
'80 98439 9991 997 -50.000' should be Type = 80 Code = 98439
'0000058916 00000074000039708' should be Type = NULL Code = NULL
'0000058916 00000074000039708' should be Type...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 22, 2007 at 9:15 pm
My bad... didn't read your post correctly... didn't realize the code that you posted was a snippet that would be used with the CTE.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 22, 2007 at 8:29 pm
JOIN #source s1 ON s1.cuslink = s.cuslink AND s1.[sequence] <= s.[sequence]
That'll work just fine... provided that the CusLink groups don't get large... and they don't need to get real large...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 22, 2007 at 8:18 pm
The vb program will split the strings and remove unnecessary values such as 0's, and converts strings to datetime.
Yep... you're right... database sure can't do any of that ;)...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 22, 2007 at 8:05 pm
Test it I did...
Server: Msg 170, Level 15, State 1, Procedure fnNumAlphaFmt, Line 29
Line 29: Incorrect syntax near '9'.
If you believe that the numeric portion will never exceed that...
--Jeff Moden
Change is inevitable... Change for the better is not.
November 22, 2007 at 7:43 pm
Do you get any error messages?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 22, 2007 at 7:10 pm
Viewing 15 posts - 53,986 through 54,000 (of 59,072 total)