This is why service, application, and user accounts should not be members of the SYSADMIN or DBO role. That would help prevent mysteriously dropped objects and also narrow the list of suspects ...

The default trace would be your best bet. However, if it's not running or for whatever reason doesn't appear to return what looks like a DROP statement, then there are a couple of other stabs you can take at it.

The last statement sent by a connection to SQL Server hangs around in the input buffer. So, if the connection that executed the DROP is still active, and the last command it executed was the DROP, then the following may reveal it. The following will dump the last command executed for each active connection, and SYSPROCESSES will also identify each connection by username, hostname, domain name, etc.

select * into #sp from sys.sysprocesses;

declare @spid int = 0;

while @spid >= 0

begin;

select @spid = min(spid) from #sp where spid > @spid;

if @@rowcount >= 1

begin;

select * from #sp where spid = @spid;

dbcc inputbuffer( @spid );

end else break;

end;

This is even less hopeful. I'm not sure if a DROP statement would be included here, just like default trace it gets cycled out over time, and I'm not even sure how to join back to a specific connection. However, because it's looking at this from another angle, it might still reveal something useful. What it does is query cached statment plans looking for any reference to a DROP.

SELECT deqs.last_execution_time, dest.TEXT AS [Query], *

FROM sys.dm_exec_query_stats AS deqs

CROSS APPLY sys.dm_exec_sql_text(deqs.sql_handle) AS dest

WHERE dest.TEXT like '%DROP%'

ORDER BY deqs.last_execution_time DESC;