May 6, 2014 at 2:27 am
There is a way to create a version control within the database without the need of third party tools. It involves creating a database trigger and the current development operation (i.e. save the stored proc version).
This is useful for having a version of the objects being worked on but it will need a pretty good interface for it to be friendly. But bottomline, we should have a version for everytime we save a stored proc.
Let me know if this line is interesting. Thanks!
May 6, 2014 at 2:29 am
There are free tools out there... 😉
edit: didn't notice this thread was in the Articles Requested forum.
It might be interesting yes 🙂
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
May 6, 2014 at 9:01 am
Sure thing. It would be interesting to see how this works for you.
May 7, 2014 at 9:03 pm
http://www.sqlservercentral.com/scripts/source+control/66285/
May 7, 2014 at 9:45 pm
Here's the summary for it.
Over the years I have reviewed different source controls and have implemented TFS. I'm a DBA at heart it's not nice nice not being able to have a source control for database development especially that clients cannot afford the expensive ones.
I came upon a database trigger post which I modified to make a rough version control for our team.
It involves 2 things
1. Create a Trigger on the database where you want versioned
2. Create a database to save the versions of the things your working on. The DB need only contain 1 specific table.
How does it work
1. This tool saves every time you make changes on your objects -- assuming that the way you save your changes is by running it.
These include the following
- Views
- Tables
- Stored procs
- Functions
2. The database trigger event takes care of the saving. Everytime you press F5 on a alter proc, it will save a copy of your work on the target table which is preferably on another database on the save server.
3. To retrieve the data, you just need to query the data in the table.
The Database Trigger
CREATE TRIGGER [DDLTrigger_Sample]
ON DATABASE
FOR CREATE_PROCEDURE, ALTER_PROCEDURE, DROP_PROCEDURE,ALTER_SCHEMA, ALTER_FUNCTION,CREATE_FUNCTION,DROP_FUNCTION,ALTER_VIEW,CREATE_VIEW,DROP_VIEW,RENAME,ALTER_TABle,CREATE_TABLE
AS
BEGIN
SET NOCOUNT ON;
DECLARE
@EventData XML = EVENTDATA();
DECLARE
@ip VARCHAR(32) =
(
SELECT client_net_address
FROM sys.dm_exec_connections
WHERE session_id = @@SPID
);
INSERT AuditDB.dbo.DDLEvents
(
EventType,
EventDDL,
EventXML,
DatabaseName,
SchemaName,
ObjectName,
HostName,
IPAddress,
ProgramName,
LoginName
)
SELECT
@EventData.value('(/EVENT_INSTANCE/EventType)[1]', 'NVARCHAR(100)'),
@EventData.value('(/EVENT_INSTANCE/TSQLCommand)[1]', 'NVARCHAR(MAX)'),
@EventData,
DB_NAME(),
@EventData.value('(/EVENT_INSTANCE/SchemaName)[1]', 'NVARCHAR(255)'),
@EventData.value('(/EVENT_INSTANCE/ObjectName)[1]', 'NVARCHAR(255)'),
HOST_NAME(),
@ip,
PROGRAM_NAME(),
SUSER_SNAME();
END
GO
SET ANSI_NULLS OFF
GO
SET QUOTED_IDENTIFIER OFF
GO
ENABLE TRIGGER [DDLTrigger_Sample] ON DATABASE
GO
The Table
CREATE TABLE [dbo].[DDLEvents](
[EventDate] [datetime] NOT NULL,
[EventType] [nvarchar](64) NULL,
[EventDDL] [nvarchar](max) NULL,
[EventXML] [xml] NULL,
[DatabaseName] [nvarchar](255) NULL,
[SchemaName] [nvarchar](255) NULL,
[ObjectName] [nvarchar](255) NULL,
[HostName] [varchar](64) NULL,
[IPAddress] [varchar](32) NULL,
[ProgramName] [nvarchar](255) NULL,
[LoginName] [nvarchar](255) NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
SET ANSI_PADDING OFF
GO
ALTER TABLE [dbo].[DDLEvents] ADD DEFAULT (getdate()) FOR [EventDate]
If you find this interesting, I'd like to take a shot at an article for it. If not, nice to have posted here and shared :).
May 8, 2014 at 6:08 am
That looks like an approach to audit changes. Is it full source-control? That is, can I, using your idea, see who changed what specifically (not just that a proc or table ddl changed, but what changed -- that is, what the old was and what the new is)? Would I be able to rollback/revert a change at will? What convention would you use for capturing the reason for a change? How would you relate two or more related changes (that is, a changeset)?
May 8, 2014 at 9:27 am
Take a shot as an article. It's an interesting solution, though it does miss the diff/branch/merge aspects of VCS.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply