Can you use the real inner join syntaxe. You might have a big fat series of cross joins in that query.

Can you post the execution plan?

Restored with the wrong backup??

Try to catch the parameters that cause the wrong execution plan. You'll most likely see a big difference in teh execution plan (scan instead of seek).

Do a search on...

You can also look under Alter database for more pointers .

I think you need to read today's article for embarassing :

The DBA Whoops

I think it's time for a shameless plug

IF Object_id('ListTableColumns') > 0

DROP FUNCTION ListTableColumns

GO

CREATE FUNCTION dbo.ListTableColumns (@TableID as int)

RETURNS varchar(8000)

AS

BEGIN

Declare @Items as varchar(8000)

SET...

The way you're doing it is fine. If the error is too severe, the server will rollback that transaction. Then you can check if any transactions are still...

Not possible.

If you need a parametered module to send a select that can be used in a join or a view, you have to make it as a table function.

Can you imagine how much work would go into that one????????

I vote we learn to be carefull and have BACKUPS.

## is global to ALL USERS

# is global to the connection (so the proc can run simultaneously with multiple users)

As I said I would opt for a perm table for...

Depends of the severity of the error. Sometimes the execution stops right at the error and exits the proc. Otherwise the code you posted should work.

Noticed it with Access 2k .

Gives a second option. Less risk of sysobjects deadlocks. Can be faster under certain circumstances. But the fact is that you have to test in your environement...

Don't need a picture box on a web page. All you need is :

Looks up the source code for this...

That'S why you should derived tables and inner joins instead of in() .