Can't run SQL DTS package after snapshot replication

We have SQL Server 2003 running on a Windows Server 2003 ("Server"). On a nightly basis, the data tables (only) of a database called "ABC" are FTP'd to our Server. We also keep a working copy of the ABC database on the server called "ABCCopy" which has, in addition to the data tables, any other views or stored procedures we have developed. A DTS package executed nightly will drop, and copy back, the data tables in ABCCopy from ABC, but will not drop or change any of the views, sp's, etc. The data tables change structure fairly frequently (usually in the form of added fields).

I and another person are usually the only people working with the ABCCopy database (we both had SQL Server 2003 on our local machines). We normally used our own DTS packages from Enterprise Manager to copy the Server ABCCopy to our local machines. No problem. However, I just recently installed Visual Studio 2005 which came with SQL Server 2005, so I installed that on my client machine (call it "Client B") to "check it out".

On Friday, when I tried to run the DTS package I usually use under "Legacy > Data Transformation Services," I received the message:

So I downloaded it, installed, it and kept on getting the above message. Getting nowhere, it seemed, I ended up creating a snapshot publication on the "Server" and a Subscription publication on my machine ("Client B"). No problem, lovely.

However, the following Monday, she noticed that (a) it didn't appear that the DTS package which copied the data from ABC to ABCCopy had worked since the publication / replication was put into place on Friday, and (b) she receives the following error when attempting to copy down ABCCopy from the server to her machine ("Client A"):

(...which makes me wonder if this is truly a snapshot or a transactional replication)

She WAS able to run the DTS package as long as she didn't drop the data tables first, but as described previously, she does that to ensure that the structure changes are brought down from ABC.

I guess the issue involves several different questions, the main question is what is the best strategy to perform these transformations / replications? Can they co-exist? Why can't I perform the legacy DTS package I had previously? Can she "unlock" the database ABCCopy from replicating with SQL Server 2003 (i.e., without SQL Server 2005 - I am out of the office frequently)?

You can't have snapshots accross instances, never mind servers. So if this is on a different machine, then you are either doing database mirroring, peer-to-peer replication or log shipping. If you were log shipping, you would know about it.

This is a replicated table, which then cannot be dropped. The alternative is to break mirroring, drop the table, backup the log (and database), resynchronise your databases and then remirror - a pain the the ... you get the picture.

If it was a snapshot (which must be on the same instance), you could drop the table. SQL actually uses the NTFS COW (copy on write, which is actually copy before write) and would update your snapshot with the entire table contents before the drop table.

(Also, not sure what this SQL Server 2003 is - there is SQL 2K and SQL 2005)

Ever needed a SQL 2008 Database replicated/mirrored/log shipped on another server but you can't take the downtime inflicted by initial snapshot or disconnect while T-logs are restored or mirror applied?
You can use SQL Server Initialize from Backup…

Familiarize people with the process of utilizing SQL Server functions from within Microsoft Access. Microsoft Access is a very powerful client/server development tool. One of the SQL Server objects that you can interact with from within Microsoft Ac…