Is it possible to disable Change History Table in schemachange?
No, it's not possible to disable it. It's the metadata repository of all changes:
https://github.com/Snowflake-Labs/schemachange/tree/master#change-history-table
schemachange records all applied changes scripts to the change history
table. By default schemachange will attempt to log all activities to
the METADATA.SCHEMACHANGE.CHANGE_HISTORY table.
Related
I am trying to implement a way to track changes to a table named gsbirst_Objects and gsbirst_Objects_Backup. It will record DML and Truncate statements
I have a stored procedure that will update the main table when it is called. How can I capture changes at the beginning and end when the stored procedure is called
I have created the backup table
I did this a while back using triggers it isn't the best way but works. You can create an audit table them build a trigger for each action. I made a trigger ON DELETE, ON UPDATE, and ON INSERT. I would then grab the record that was changed up dated or deleted and concatenate the row together and load a before and after into the audit table depending on what happened. This route for me gave me a little more detailed even of what happened and what changed.
Currently I have CDC enabled on a table DATA_Sale. I want to disable the logging of any new changes but want to keep the CDC for records. Is this possible?
The process of disabling CDC on your table will cause the corresponding system table that's been capturing the changes to be dropped, as noted in the documentation that #SeanLange posted in the comments, sys.sp_cdc_disable_table.
But knowing that the system table will go away just means you have to plan for that.
First, you probably want to stop capturing new changes, unless you have other capture instances running:
EXEC sys.sp_cdc_stop_job #job_type = N'capture';
Now make a copy of the system table, and port your data over to it. 'SELECT ... INTO ...` will do. You can tweak the structure later if you need to.
Then go ahead and disable the capture.
I am trying to convert my DB to be Azure SQL V12 compatible which requires removing all file groups except for PRIMARY. I've migrated all PK and INDEXES to be on primary. Now I have only some tables that specified TEXTIMAGE_ON that are not in the primary file group. here is the current table definition:
CREATE TABLE [dbo].[HistLocation](
xxxx
) ON [PRIMARY] TEXTIMAGE_ON [HIST]
I tried doing the steps in this link: https://www.jitbit.com/alexblog/153-moving-sql-table-textimage-to-a-new-filegroup/
But when I try to save the file it states:
"Saving changes is not permitted, The changes you made require the following tables to be dropped..."
Is there another way around this?
I would strongly suggest that you use T-SQL to make changes, or at the very least, preview the scripts that the Designers generate before committing them. However, if you want to do this in the designer, you can turn off that lock by going to Tools...Options...Designers..Table and Database Designers.. and unclick the "prevent saving changes that require table re-creation".
That lock is on by default for a reason; it keeps you from committing some change that is obfuscated by the designer.
EDIT: As noted in the comment below, you can't preview the changes unless you disable the lock. My point is that if you want to use the table-designer to work on a table with this feature disabled, you should be sure to always preview the changes before committing them. In short, options are:
BEST PROCESS: Use T-SQL
NOT GREAT: Disable the lock, use Table Designer, and ALWAYS preview changes
CRAZY TALK: Click some buttons.
Hi I have accidently updated a row in SQL-SERVER that I should not have is there anyway to get the previous value of the row using this query:
UPDATE Documents
SET Name = 'Files'
WHERE Id = 950
Is there any way to recover the previous value?
Yes, it is possible, but only under certain circumstances.
If you had wrapped the UPDATE in a transaction, you could ROLLBACK. This would undo the UPDATE.
Assuming you didn't put it in a transaction, you need to reset the database to a previous point in time. This is only possible if you have some form of back-up on the database. How to do this is shown in this MSDN page
Not that both of these options will UNDO the update, not just tell you the previous values.
The table doesn't have a last updated field and I need to know when existing data was updated. So adding a last updated field won't help (as far as I know).
SQL Server 2000 does not keep track of this information for you.
There may be creative / fuzzy ways to guess what this date was depending on your database model. But, if you are talking about 1 table with no relation to other data, then you are out of luck.
You can't check for changes without some sort of audit mechanism. You are looking to extract information that ha not been collected. If you just need to know when a record was added or edited, adding a datetime field that gets updated via a trigger when the record is updated would be the simplest choice.
If you also need to track when a record has been deleted, then you'll want to use an audit table and populate it from triggers with a row when a record has been added, edited, or deleted.
You might try a log viewer; this basically just lets you look at the transactions in the transaction log, so you should be able to find the statement that updated the row in question. I wouldn't recommend this as a production-level auditing strategy, but I've found it to be useful in a pinch.
Here's one I've used; it's free and (only) works w/ SQL Server 2000.
http://www.red-gate.com/products/SQL_Log_Rescue/index.htm
You can add a timestamp field to that table and update that timestamp value with an update trigger.
OmniAudit is a commercial package which implments auditng across an entire database.
A free method would be to write a trigger for each table which addes entries to an audit table when fired.