Why get tables cleaned and copied in an SQL-Server DB?

Question

I'm working on an SQL-Server database.

Regularly, entries from one table get moved to another one (from entries to Log_Entries) in order not to flood the database. (The Log_Entries get cleaned afterwards too)

I would like to know how this works, but I don't find any corresponding entry in the "Stored Procedures" or "Functions" and there seem not to be any "Database Triggers". Also the "Rules" part of the database seems to be empty.

Which entry in the database can be responsible for such a task?

Edit after first comment
I have "Database Diagrams", "Tables", "Views, "External Resources", "Programmability", "Service Broker", "Storage" and "Security".
Within "Programmability" there are "Stored Procedures", "Functions", "Database Triggers", "Assemblies", "Types", "Rules", "Defaults" and "Sequences".

Where is that SQL Agent?

Thanks in advance

• Denis Rubashkin: SQL Agent Job maybe?
• Dominique: @DenisRubashkin: where can I find those? (I've edited my question accordingly)
• Denis Rubashkin: View a Job
• J.D.: The SQL Agent is at the end of the list of "folders" in SSMS. If you don't see it, that means your account doesn't have permissions to SQL Agent, and you'll need further access granted by someone who has SysAdmin access. At a minimum you need the SQLAgentUserRole granted.
• SMor: Previously you were using SQL Server Express - which does not support the Agent. Have you simply tried ASKING people who are familiar with this database and the system in which it is a part? This logic might be containined within a program - so you can't "find" it within the server instance at all.

Answer 1

You can find if there's a job that refers to a specific table using this query:

SELECT j.name,
 s.database_name,
 s.command
FROM msdb.dbo.sysjobsteps s
 INNER JOIN msdb.dbo.sysjobs j
 ON s.job_id = j.job_id
WHERE s.command LIKE '%TableName%' 
 AND s.database_name LIKE '%DatabaseName%';

It's not 100% safe method though as your job might refer to a stored procedure which refers to the table. Yet, I recommend using it since you could be lucky enough to find the job you're looking for and save time going through each job manually.

• Dominique: It's a good attempt, but I didn't find what I was looking for (there were only some "purge" related jobs).
• Ronaldo: @Dominique, you could use one approach like these to find what's causing the changes. But you're gonna have to adapt them to capture the delete/truncate on the table Log_Entries, for example.