Have you tried REPLACE?

UPDATE MyTable

   SET MyColumn = REPLACE(MyColumn,

               ...

You could have a look at :

- MySQL : one of the biggest around. Is good for performance, but rather scarse in functionality (no views, stored procs, ...)

- PostGRE :...

Just use

SELECT * 

FROM IMS

WHERE IMS.USAGE_CODE <> "PRIVATE"

   OR IMS.CREATE_BY = m_UserId

If you pass the query as a string into a 'command' or 'recordset'...

Guess this depends on your environment.

One of our customers schedules a big Disaster Recovery test each year. Takes backups (of the complete system), goes to the backup Data Center and...

I would think you use a WHERE clause...

SELECT <required fields>

FROM MyTable

WHERE (creator_id=@user_id

   OR USAGE_CODE = 0)

   <Any additional selections> 

Replace @user_id with...

To exclude weekends, there is a 'simple' solution doing some simple 'date'math. This has been solved before on these forums...

To also exclude holidays is a lot trickier. The only 'easy'...

quote:

---

Uh, you realize that this will add all rows into your audit table even if only one of them has this...

Could this be the 'infinite loop' problem inside the procedure. Opening a cursor but not fetching the next record might not impact performance of other queries too heavily, but it...

The problem with the @@IDENTITY has nothing to do with your transaction.

@@IDENTITY returns the identity value of the last insert in the database. It does not take different tables, transactions,...

And now to the topic again...

I do believe adding XML support to SQL Server is good. It gives you an additional interface to the system.

Just to add an additional topic to the discussion...

The problem with XML is that it defines a notation you have to adhere to.

So, suppose all of the applications in the...

You cannot get around the limitations of the 'if UPDATE()' statement.

Unless you use another kind of test like 'EXISTS'.

But then again, doing the INSERT with no rows anyway is certainly...

Doing a rollback like this is probably the best way.

However, you do not catch any errors in the 'second' level inserts.

From a syntax point of view, this is correct. @@identity is a bit like @@error or @@rowcount. It gets populated with every query.

However, using @@identity, you could run into problems,...

Stored Procedures is the way to go to prevent SQL Injection.

Parsing out 'dangerous' characters could achieve a relatively high level of security, but it does impact the possibilities for a...