ok...i see the plan...but it goes back again to what will the table be used for? the purpose of the table has a lot to do with the best way to tackle this...

there's lots of built in options, but can you describe what you'd d0 with he data in the table after it exists?

is it just an audit(so you could use a trace instead?) so you can fingerpoint or otherwise know who did what?

is it to be able to undo unwanted changes?

is it to satisfy a SOX requirement or something?

but what about the following?

what about a table that doesn't have a single column for it's primary key? admittedly, depending on your biz, you might always have a single column PK, but i know i have quite a few that do not.

if you are consistent, and every table's PK happens to be an identity, you could use bigint instead of varchar(1000) for the definition.

what happens when, say 5 columns in a table were changed? you want 5 rows in the audit table added? very hard to write a script to undo that, because since the value is in a nvarchar(max0, you have to custom write the script , with CONVERT commands sometimes, and merge those 5 rows back into a single one, for all the rows affected.