views:

4644

answers:

3

I am trying to become more efficient in my SQL programming. I am trying to run a loop to repeat an update command on field names that only change by a numerical suffix.

For example, instead of writing out x_1, y_1, then x_2, y_2 for each update:

DECLARE @a INT 
DECLARE @b VARCHAR 

SET @a = 1
WHILE @a < 30
set @b = @a
  BEGIN
       UPDATE source set h = h + "x_"+@b
           where "y_"+@b = 'Sold'
    SET @a = @a + 1
  END

Let me know if I can clarify. I'm using SQL Server 2005.

Thanks for any guidance.


I'm trying to apply Adams's solution and need to understand what is proper usage of N' in the following:

exec sp_executesql update source_temp set pmt_90_day = pmt_90_day + convert(money,'trans_total_'+@b'')
    where convert(datetime,'effective_date_'+@b) <= dateadd(day,90,ORSA_CHARGE_OFF_DATE)
    and DRC_FLAG_'+@b = 'C'
+4  A: 

This won't actually work, as you can't have the column name in quotes. What you're essentially doing is having SQL compare two strings that will always be different, meaning you'll never perform an update.

If you must do it this way, you'd have to have something like...

DECLARE @a INT 
DECLARE @b VARCHAR 
SET @a = 1

WHILE @a < 30
BEGIN
set @b = @a  
exec sp_executesql N'UPDATE source set h = h + 'x_'+@b + N'
           where y_'+@b + N' = ''Sold'''   

SET @a = @a + 1
END

In general, however, I'd discourage this practice. I'm not a fan of dynamic SQL being generated inside another SQL statement for any sort of production code. Very useful for doing one-off development tasks, but I don't like it for code that could get executed by a user.

Adam Robinson
+1 For a good answer and a good explanation of why not to use it. Wish I could give +10.
Michael Todd
Adam, if you could assist in my regards to my revision i would appreciate it.
homerjay
@homer: N' creates an nvarchar, rather than a varchar. It's a string quoting identifier. Example, N'This is my string' is an nvarchar, and 'This is my string' is a varchar. I used N' because sp_executesql takes an nvarchar.
Adam Robinson
A: 

Adam hit a lot around the problem itself, but I'm going to mention the underlying problem of which this is just a symptom. Your data model is almost certainly bad. If you plan to be doing much (any) SQL development you should read some introductory books on data modeling. One of the first rules of normalization is that entities should not contain repeating groups in them. For example, you shouldn't have columns called "phone_1", "phone_2", etc.

Here is a much better way to model this kind of situation:

CREATE TABLE Contacts (
     contact_id INT NOT NULL,
     contact_name VARCHAR(20) NOT NULL,
     contact_description VARCHAR(500) NULL,
     CONSTRAINT PK_Contacts PRIMARY KEY CLUSTERED (contact_id)
)

CREATE TABLE Contact_Phones (
     contact_id INT NOT NULL,
     phone_type VARCHAR(10) NOT NULL,
     phone_number VARCHAR(20) NOT NULL,
     CONSTRAINT PK_Contact_Phones PRIMARY KEY CLUSTERED (contact_id, phone_type),
     CONSTRAINT CK_Contact_Phones_phone_type CHECK (phone_type IN ('HOME', 'FAX', 'MOBILE'))
)

Now, instead of trying to concatenate a string to deal with different columns you can deal with them as a set and get at the phone numbers that you want through business logic. (Sorry that I didn't use your example, but it seemed a bit too general and hard to understand).

Tom H.
A: 

while @count<@countOfSession begin if @day='Saturday'or @day='Tuesday' begin if @day='Saturday' begin select @date set @day='Tuesday' set @count=@count+1 set @date=@date+3 end else if @day='Tuesday' begin select @date set @day='Saturday' set @count=@count+1 set @date=@date+4 end end end