Freaked out

3PM, all three developers from the same project (the only ones working on that project) came over and asked if I was running anything against their client-test database. I haven't been in Oracle all day and no one else in our team was running anything either. Problem is, 2 tables mysterioulsy appeared in the main schema, created at 3:08PM. One was called "New Table" and the style of the create script is not the standard we use in Oracle. OK so I believe the developers that it wasn't one of them who did it. Checked the database and there were no suspicious login accounts in the sessions list. Had a look at the history for SQL statements executed. Wola there it was, executed by the application's system account! But everyone who knows the password said they didn't executed the statements..

The table name gave it away that it was created by a GUI tool and defaults the name to "New Table". So which tool? Access doesn't - it calls it Table1. But MS SQL Enterprise Manager does! No jobs on our servers ran any transfers at 3, and the only server with a link to the Oracle database is dvel. But for someone to create a table via linked server, they will need to know the password to the account, which is a different account from the one that executed the statement.

Turns out that the developer who did it (by mistake) is on another project, and who doesn't know any of the passwords in question. How? He copied a DTS in dvel that connects to the Oracle client-test database and modified it. That way the connection details are still intact and he could do whatever the account details in the DTS package allows. He didn't mean no harm. So it wasn't a hack which is a big relief. Tomorrow we'll be doing so spring cleaning to clear out any undesirable DTS packages and server logins.