I have a unknown job that is deleting records from a table on SQL server 2005. We can't find it yet. Any of you have a clue of how can we know wish stored procedure or job is deleting this records in a X table?. Is there any way to know or record on database that can tell us specifically, "this sp or job delete records from that table in this date and hour"?.
2 different approaches:
Add a trigger (For Delete) to gather the name of the logged-in user: suser_sname() or the running app. You will need to create a table to store this information (commonly known as an Audit table).
Use the Profiler to watch all traffic on the database.
The trigger approach is better and you can even block/reject/abort delete commands on a per-table basis.
Related
I need to simulate an AFFER insert trigger on a table in a linked server Database that is read only from a Vendor.
I can't change the table but I can read.
Beside creating a stored proc on our server and schedule it to run every X minutes to get net changes, can someone point me to a design more dynamic?
Thank you.
I would like to create a job in the Management studio. This job needs to check if there are "new" or if there are "changes" in one table of access. This must run every 5 min.
If I create the job the next pop up will come.
What should I fill in the command section?
The check must come from this table "GRV_Audit_ChangesCreditorBankaccount"
It really depends on what you're trying to do -- send an email notifying of the insert/update, record details of the insert/update in another table or database, or even rollback or prevent the insert/update.
The possibilities are numerous.
You probably need to ask yourself (or your boss or whomever made the request): What action do you want to take place when data in the target table(s) is updated or inserted?
It may well turn out that a SQL Agent job isn't fit for purpose. You may end up looking at triggers or database auditing to achieve your goal.
You could try investigating this as a possible solution...
Create an empty table with the same structure as your bank account numbers table.
Add an AFTER TRIGGER on your original table that additionally inserts data into your new table whenever the original table is updated
https://learn.microsoft.com/en-us/sql/t-sql/statements/create-trigger-transact-sql?view=sql-server-ver15
Alternatively, if you are on SQL Server 2016 or greater, you could implement your bank account numbers table as a temporal table, which more or less does the same as the above automatically.
https://learn.microsoft.com/en-us/sql/relational-databases/tables/temporal-tables?view=sql-server-ver15
I have a table for bio-metric devices which capture the data as soon as the employees punch their fingers and uses SQL Server 2014 Standard Edition.
However, our legacy devices were exporting log files and we used a vb engine to push to our Oracle table and used to generate the attendance details.
I managed to export the data from SQL Server and built the first set of records. I would like to schedule a JOB with SQL Server with a condition that the Oracle table should receive ONLY the rows those are NOT already inserted from the SQL Server table.
I checked the append possibilities, which dumps the entire SQL Server table data when the job is executed thus duplicating the rows within the Oracle target table, forcing me to discard the job and to build a new one that deletes the Oracle table and recreates when the job is executed. I feel this is a kind of overkill...
Any known methods available to append only the rows those are NOT existing in the Oracle target table? Unfortunately the SQL Server tables doesn't have any unique id column for the transaction.
Please suggest
Thanks in advance
I think the best way is to use sal server replication with Oracle database as subscriber.
You can read about this solution on MSDN site:
Oracle Subscribers
Regards
Giova
Since you're talking about attendance data for something like an electronic time card, you could just send the data where the punch time is > the last time stamp synced. You would need to maintain that value some where, and it doesn't take into account retro actively entered records. If there's a record creation date in addition to the punch time you could use the created date. Further if there is a modified date in the record you could look into using the merge statement as Alex Pool suggested so you could get both new records and modifications synced to oracle.
I have a SQL Server 2008 database. I need to capture Insert/Update/Delete operations on every table in the DB, take the affected primary key and insert into another table ChangeLog. ChangeLog needs capture the PK, source table, operation type.
I don't want to write triggers for every table. Whats the simplest way to do it?
Use case : I connect to SQL Server from Solr. The change log is used for delta import.
I'd start by taking a look at SQL Server Change Tracking and see whether it'll do what you need. It's built in and simple enough to access:
Change Tracking Overview
You don't want to write a trigger for every table because you think it is hard.
Query for a list of each table
Query for each table's primary key
Create a trigger script for add, update and delete to write to the ChangeLog table using the data for each table and primary key.
It's really not that hard to build this script and apply it to your database. If you can write it for one table, you can automatically build scripts for each table. With an error check (does trigger exist), you can run this as new tables are added.
Is there a way to replicate a sql server database but not push out deletes to the subscribers?
You don't mention which version of SQL Server you're running, but Andy Warren wrote an article on configuring INSERT, UPDATE, and DELETE behaviour in SQL Server 2005. You can configure this through the GUI, using his instructions:
http://www.sqlservercentral.com/articles/Replication/3202/
It's tempting to 'intervene' in a normal replication and 'disarm' the subscriber's side delete stored procedures, but this leaves no option to recover from replication failure. If the replication tries to recover, a reinitialize may be needed and this will drop any 'stale' data that the replication agent considers deleted.
An alternative is to use a normal replication, and use a script that generates insert and update triggers on all tables in the subscriber database, that insert/update that data into yet a third database. This way the third DB will collect all the data that ever existed, the second DB can re-initialize it's subscription if it needs to (when you do, just remember that bulk inserts don't call the insert trigger and check for new data and add it to the third DB), and the first DB doesn't have to perform the extra work that the triggers are.
Do this....Drop the article. Create a new storedprocedure in the corresponding database that mimicks the system store procedure (sp_del...) and contains the same parameter but does nothing. Add the article again...and set the delete store procedure under the article's properties to the new delete stored procedure that you created....
Or you can select Do not replicate Delete Statements....I think that works but i haven't tried it.