Personally, as I get older, I don't want a cannon. Hard on the wrists and arms.

Moving to the SQL 2012 forum. This was posted in SQL 2000.

In 2012, you might be able to do something with xEvents and a trigger when you get xx logins...

erichansen1836 (9/25/2015)

---

I See perhaps your point now, that I am actually performing 2 separate COMMITS, 1 to 1 MDB file, and

another to the other MDB file. DO you still...

One thing you might try is using row_number or some other counter based on the rows to retrieve only the PKs needed for that set of data. Then join that...

jasona.work (9/25/2015)

---

I've been wanting to pile into that topic, but keep restraining myself...

Hmm. Maybe we need to Godwin that topic, and bring in a comparison somehow to the Fuehrer?...

The tables are stored in pages, and those in extents. Those get allocated, and depending on the way they're allocated and data is added/deleted, it's possible the allocations don't match....

Ross.Sp (9/24/2015)

---

It's a bad idea to have sensitive data (e.g. a copy of Production data) in a Dev environment and it may actually be in breach of privacy laws and...

We've put together some learning links for you if you want to learn more about this (or other) new feature(s).

http://www.sqlservercentral.com/articles/Dynamic+Data+Masking/127554/

From an audit/risk perspective, yes, they can read data in a diff file, as noted.

In terms of mitigating risk, you can use encryption, which isn't perfect, but nothing is. However...

As Lowell noted, the procs will be in sys.objects. They'll see them in SSMS. AFAIK, you can't hide that.

I think, searching memory here, that you could get SELECT privileges to the job tables and grant them. However that might mean the person could only query.

As far as DTS,...

There's the SP_OA procedures, but they would contain similar risks. Is this SQL 2000? If so, then the risk is that someone will run some malicious code on the Windows...

The immediate risk is that you write a poor query and delete the wrong data.

There's no logic in SQL Server for this. You'd need something to scan the SQL log and send you an alert. However, you'll need to define this. Do you mean...

Do you mean a tally table?

Search "tally table" here for Jeff Moden's article on building one.