The algorithm used for SQL logins isn't documented.

Why do you need it?

In this case no assumption was needed, since the OP said

If it happens consistently, schedule a server-side trace to start just before the problem occurs and run long enough to catch the entire thing, then you can review the trace...

Yes it should, because you have no explicit transactions.

In snapshot isolation, read queries will show the data version as of the time their transaction started. You have no explicit transaction,...

Can I get my lost points back? :crying:

So the server is intended as a reporting/analysis server (read-only access to production data), not a development server (where developers are actively working on new features and changing existing features)?

But you wouldn't be doing it in those 30 hours. The advantage of the mirror/log shipping method is that you get the large copy done well in advance (weeks even)...

Snapshots are read only, log shipping secondaries are read only.

I have to ask, because the reason for needing up to date data will affect appropriate methods. If it's a reporting...

If Field in Table1 is ever null, that query would return no rows. However since that's the primary key, it's not nullable and hence you don't have that concern

The DMV should be transactionally consistent. This isn't the sysindexes from SQL 2000 era which could be and was wrong at times.

Either one will do, if it's a once-off (which it should be), it really doesn't matter which you use.

If you log ship, then your dev database will be completely read-only. Mirroring's worse, the DB isn't accessible at all. Kinda defeats the point of a development server.

Why do you...

Nothing wrong with a disabled login owning objects or being the grantor of rights.

Typically with something that size, I'd set up log shipping or mirroring before the planned migration day, then all I have to do on migration day is fail over the...

None.

No you didn't. You changed one file to have an initial...