Viewing 15 posts - 53,566 through 53,580 (of 59,098 total)
Mindy, the problem is that you have the data stored in a CHAR(32)... trailing blanks come into play there. Either change the column to a VARCHAR(32) or modify my...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2007 at 10:41 am
jeff ...there is no other go, i want ot use only dynamic sql
Heh... you must not have looked because I gave you dynamic SQL. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2007 at 10:29 am
Sorry... not seeing the pattern here between the inputs and the desired output... would you explain how you want the concatenation formed better, please? Also, see the following if...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2007 at 9:58 am
Actually, if you look at the bigger picture, you have a much larger problem... why would you select from 3 different tables into 1? Except, possibly, for reporting, you...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2007 at 9:29 am
if you want to pass parameters into dynamic sql, then you MUST use sp_executesql.
I guess that depends on what you're calling a "parameter"...
Mike, going back to your original post, the...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2007 at 9:12 am
Perfect... thanks, Matt.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2007 at 8:24 am
SELECT INTO to populate the entire recordset is painfully slow compared to INSERT INTO
Not real sure where you're coming up with that... I agree that SELECT/INTO will hold a lock...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2007 at 8:16 am
I was pleasantly surprised a few years back to see MS trot out an actual certification specifically for these folks with most of its emphasis on the SQL side, and...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2007 at 7:44 am
For so many reasons, storing dates as formatted VARCHARs is such a terrible idea. If you need to do any date math or comparison of dates, formatted dates only...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 18, 2007 at 6:40 am
Actually, here's a solution that doesn't use a temp table...
--===== Solve the problem ==========================
--===== Declare a variable to hold the delimiter
DECLARE @Delim CHAR(1)
SET @Delim = ','
...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2007 at 8:02 pm
Oh no... a "sequence" table. :hehe: Third party app we got used one... cause an average of 640 deadlocks per day because of the way they wrote the increment...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2007 at 11:36 am
Thanks for the feedback, Taffy.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2007 at 11:07 am
Jeff, your "auto magic" one came the closest but I got some extra zeros I haven't quite figured yet -
Original Modified
-------------------
A14 A00014
B2 B0002
OBT 0000OBT
YH3 YH0003
XX 0000XX
So - too many...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2007 at 11:04 am
Karthik, it looks as if your code will fail if the length of any part changes because you've hard-coded each length. Also, I wouldn't use the spt_Values table in...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2007 at 10:48 am
If you use SQL Server 2005, then you can make use of CTE as well
Ummm.... I'm pretty sure I'll avoid recursive CTE's just like I avoid Cursors... they're just too...
--Jeff Moden
Change is inevitable... Change for the better is not.
December 17, 2007 at 8:25 am
Viewing 15 posts - 53,566 through 53,580 (of 59,098 total)