I don't see table "ESHOPINVENTSUM" in the query. Is it supposed to be TEMPINVENTSUM? Or...

If you need a (very) large log, rather than a single very large allocation, you might be better off growing in somewhat smaller chunks. For example, if you need...

An overgrown log file can have too many VLFs, which can adversely affect performance.

On some disks, the autogrowth can result in a less contiguous log file, which can also affect...

Just as a possibility: Check constraints instead will reduce overhead slightly, since another table doesn't have to accessed. For a very limited number of known and easily recognized values,...

You don't need a cursor at all, just an UPDATE followed by an INSERT (or MERGE, but some people have run into performance issues with MERGE).

The table names aren't consistent,...

SELECT

OBJECT_NAME(object_id) AS table_name

FROM sys.columns

WHERE

name IN ( 'col1', 'col2', 'col3' ) AND

OBJECTPROPERTYEX (object_id, 'BaseType') IN ( 'U', 'V' )

GROUP...

I suggest this method:

DECLARE @date datetime

--@date is used just to make it easier to check other dates:

-- naturally you can hard-code GETDATE() in place of @date if...

Sean Lange (9/13/2013)

---

If you handled all of your updates via stored proc this would be even easier. 😛 Just add another column to the update statement. If however, as it...

4 tables of between 1M and 2M rows shouldn't take much time to run, except on a very limited server.

There must be something in the query that is causing some...

Some points to consider:

Be sure to make the search value a character string, viz:

SET @MySearchCriteria = '''3496'''

"Max_length" is bytes, which works fine for (n)(var)char, but not so much for int,...

A trigger is the best way to handle that.

In a D/R situation, it might be a royal pita to have only AD accounts to have access to the instance.

I'd rather be able, in a genuine emergency, to bring...

WHERE

Docket_Date >= DATEADD(MONTH, DATEDIFF(MONTH, 0, @date1), 0) AND

Docket_Date < DATEADD(MONTH, DATEDIFF(MONTH, 0, @date1) + 1, 0)

I would never allow the sa password to be the same on more than one instance. The sa account is to be used only in an emergency anyway (such...

No, it's not a good idea. SQL will typically not be able to generate as good a plan for remote tables as it does for local ones.