Probably the easiest work-around is likely a DDL trigger that prevents them from issuing any DROP TABLE (and ALTER TABLE on a table they didn't create, if you need that,...

You need to back up and actually do logical data modeling (Google "logical data modeling") not table modeling.  You literally cannot normalize what you posted because there are no usable...

• This reply was modified 6 years, 3 months ago by ScottPletcher.

Ok, interesting.  Can you give an example of code that is indefinitely executing?  Are you sure it is this sp_executesql code and not some other code in the proc?

[Yes, I...

2. ... [H]ow to address this problem ?

That depends on the specific details in this situation.

2A. How many rows are in the remote table?

2B. How much data do you need...

A basic numeric calculation should not take long to execute.  Look at the @ParmDefinition and make sure that it is not a calling stored procedure or doing something else that...

Don't see anything directly wrong the calcs, although you should not do a calc on every LogTime column in every row, you should compare LogTime directly to the 60-days-ago EPOCH...

A few quick thoughts (numbered to make discussion of them easier):

(1) You need to normalize this design, you're storing huge amounts of duplicate data.  Specifically, encode the database name with...

Several things that would/should help.  You can implement / not implement each one as you see fit:

1. How do you most often query the table?  By Ids or by datetime? ...

You're welcome.  Thanks for the confirmation!

Change the end of the statement from ," ","_") to:

," ","")

Also, considering that VALUES didn't actually come out until 2008, your lecture about getting rid of the old syntax "decades" ago is full of hooie.  As for someones data...

DROP TABLE #sampledata 
GO 

CREATE TABLE #sampledata
(
id int IDENTITY(1, 1) NOT NULL PRIMARY KEY, --<<--!!
folder  varchar(100) NULL,
folder2 varchar(100) NULL
)
GO 
INSERT INTO #sampledata VALUES
   ...

No, you should (almost) never need to restart...

Indirectly, yes there is, and it's a guaranteed locking approach, since it's provided by the db engine itself, and uses its own locking mechanisms internally.

Use system procs sys.sp_getapplock...

Indirectly, yes there is, and it's a guaranteed locking approach, since it's provided by the db engine itself, and uses its own locking mechanisms internally.

Use system procs sys.sp_getapplock and sys.sp_releaseapplock.

Before...