I would make it truly more generic (might as well).  Definitely avoid the use of INFORMATION_SCHEMA views, since they are not 100% reliable and often seem very slow.  I, too,...

SELECT ca.*
FROM dbo.history h2
CROSS APPLY (
    SELECT h1.*
    FROM dbo.history h1
    WHERE h1.hist_id = h2.hist_id - 1
    UNION ALL
    SELECT h2.*
) AS...

You're welcome!  I had to make one correction to the query above, btw.

Something like this:

FROM
...
dbo.Locations L ON AL.LocationID = L.LocationID OUTER APPLY (
    SELECT TOP (1) D.*
    FROM dbo.Applicant_Disposition D
   ...

• This reply was modified 1 years, 11 months ago by ScottPletcher. Reason: Added "TOP (1)" to outer apply query that I forgot to put in earlier, D'OH

View sys.database_principals will have the sid of the login (but not the login name itself).  View sys.server_principals also has a sid.

If the login has been dropped, the sid may still...

Naturally you can't use the current file names, since they're already in use for the original db.  Use "WITH MOVE" to "tell" SQL the new file names

RESTORE DATABASE ACME_DEV FROM DISK...

> So the format of the file reference for Branch A would be, A500/2024 and for branch B, B200/2024, etc. <<

That sorta violates 1NF, right?  Personally I'd suggest not doing...

Some things are somewhat unclear.

I don't see "district" at all in the ERD, although you reference it extensively in your discussion.

"Entries" is a rather vague Entity.  And it looks as...

It should be more efficient to do that using a trigger rather than doing a separate UPDATE after the load.  The trigger would also allow for indirect notification (you wouldn't...

I would think one UPDATE -- with the IN condition added -- would be much better than 3 separate UPDATEs, since the main table will then only have to be...

Typically EXISTS / NOT EXISTS is most efficient when it's a viable option.

You'll want to have a (nonclus) index on B ( AppId, NotificationDate ).  If the table already has...

Agree with Phil, that's a critical q.

Also, efficiency will depend on the indexes on the tables.  You'll need to be able to review indexes.

(dup)

Try these and see if they help.  Be sure to review the query plan to verify:

INDEX ON mq: ( TABLE_NAME, ROWID_MQ_DATA_CHANGE )

UPDATE mq
SET mq.sent_state_id = 6,
UPDATED_BY =...

It would be simpler and more efficient to just calc the 3rd Friday of the month and then see if there are any rows for that date, i.e., you don't...