Red Gate forums :: View topic - Linking the static data with SQL Source Control
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
SQL Source Control 1
SQL Source Control 1 forum

Linking the static data with SQL Source Control

Search in SQL Source Control 1 forum
Post new topic   Reply to topic
Jump to:  
Author Message
BrandonGalderisi



Joined: 07 Jul 2010
Posts: 15

PostPosted: Fri Jul 23, 2010 6:46 pm    Post subject: Linking the static data with SQL Source Control Reply with quote

I want to link tables which contain only static data to SQL Source Control. How may I do this?
Back to top
View user's profile Send private message
sherr



Joined: 19 Mar 2009
Posts: 125
Location: Cambridge

PostPosted: Fri Jul 23, 2010 7:44 pm    Post subject: Source Controlling Static Data Reply with quote

Hello,

We don't have this feature implemented yet, but there is a workaround using SQL Data Compare Pro, http://www.red-gate.com/supportcenter/Content.aspx?p=SQL%20Source%20Control&c=SQL_Source_Control/help/1.0/SSC_Source_Controlling_Data.htm&toc=SQL_Source_Control/help/1.0/toc.htm.

Please let us know how you get on with this and if this is acceptable for now? How often does your static data change? Do you have any ideas on how you would like this integrated into SQL Source Control (e.g., right-click on a table and say source control this table's data, do you need filtering options, e.g., only source control rows 5 - 20)?

Please vote/comment on this feature on our Suggestion Forum at
https://redgate.uservoice.com/forums/39019-sql-source-control/suggestions/457874-source-control-data-data-folder-is-blank-?ref=title.
_________________
Thank you!
Stephanie M. Herr Smile
Delivery Product Manager
Back to top
View user's profile Send private message
BrandonGalderisi



Joined: 07 Jul 2010
Posts: 15

PostPosted: Mon Jul 26, 2010 1:05 pm    Post subject: Reply with quote

For me, a table either does, or does not, contain static data. But I can see the value for others in being able to script only certain data.

As for whether this will work or not, it's quite cumbersome compared to SQL Source Control but I will give it an honest chance before dismissing it.

I would love to see it as a right click option with filtering.
Back to top
View user's profile Send private message
David Atkinson



Joined: 05 Dec 2005
Posts: 1111

PostPosted: Mon Jul 26, 2010 3:12 pm    Post subject: Reply with quote

Thanks for giving it a go. Yes, we recognise that it is more cumbersome that it needs to be, but we couldn't justify putting this in v1.0 in place of other 'essential' features that didn't have workarounds.

Thanks for bearing with us. Any other feedback you might have is most welcome.

Regards,

David Atkinson
Product Manager
Red Gate Software
Back to top
View user's profile Send private message Send e-mail
mcnamaragio



Joined: 15 Feb 2009
Posts: 7

PostPosted: Tue Aug 17, 2010 8:50 pm    Post subject: Static data Reply with quote

It would be nice if the static data support is added to the product. Also, it would be nice if it was possible to choose which part of the static data should go under source control.

For example,
Data that comes with default installation of my program should be source controled but the data that developer inserts through the program to check his work should not. Basically, if the data is inserted/updated/deleted from ssms then it should be in source control otherwise it should not. It would be nice if you included similar feature in the program.
Back to top
View user's profile Send private message
David Atkinson



Joined: 05 Dec 2005
Posts: 1111

PostPosted: Tue Aug 17, 2010 9:28 pm    Post subject: Reply with quote

We're in the process of designing this feature so your feedback is very useful.

Can I ask what columns exist in your static data table? What distinguishes the default installation data compared to the developer's test data? We are considering allowing a WHERE clause to be specified to designate which part of a table is the actual static data.

If you could email me a sample static data table, this would be useful.

David (David.Atkinson at red-gate.com)
Back to top
View user's profile Send private message Send e-mail
mcnamaragio



Joined: 15 Feb 2009
Posts: 7

PostPosted: Tue Aug 17, 2010 10:09 pm    Post subject: Reply with quote

I guess I didn't explain it well.

There is two kinds of static data in the database:

1. The static part of the data that comes with the installation and cannot be edited/added/deleted by the user. This should be in source control. If the developer makes changes to the data with ssms it should be reflected in source control. It can be solved with sql data compare as it is possible to limit what to synchronize

2. Preconfigured values that can be changed. For example default data for a dropdownbox. The user can add/edit/delete data from the program.

This should be in source control. However when a developer modifies some data to it through the program it shouldn't go in source control. A possible solution can be to have a isdefault column which distinguishes between default and user data. The problem with this approach is that if preconfigured record is modified or deleted from the program (so isdefault is true) it should not be changed in the source control.

Thanks.
Back to top
View user's profile Send private message
David Atkinson



Joined: 05 Dec 2005
Posts: 1111

PostPosted: Tue Aug 17, 2010 10:55 pm    Post subject: Reply with quote

1. In terms of limiting what to synchronize, how would you need to do this? Would you need to explicitly select the records within a table that you want to source control, or would you need to use a WHERE clause to specify it?

2. If a developer modifies static data records on his own development database that has previously been committed to source control, they need not commit these new changes to source control. Like any change made on the developer's personal development environment, it doesn't go into source control unless the developer commits it. If the developer has changed something just for a test, they will be able to revert back to this afterwards using the 'undo' function.

David
Back to top
View user's profile Send private message Send e-mail
Simon Quin



Joined: 17 Aug 2010
Posts: 2

PostPosted: Wed Aug 18, 2010 1:21 pm    Post subject: Reply with quote

@David

We would be very interested having static and default data under source control. Our requirements would be along the lines of:

1. Entire tables that contains system defined static data and can never be changed by the end-user.

2. Default data entries that should always be present but can be changed by the end-user: these typically have an internal value that cannot be changed but some other value that can (e.g. a description of a status in a list). Here a WHERE clause wouldn't suffice for an entire table, individual internal values would need to be selected.

3. Default data items that provide the core of values that cannot change but that can be added to by the end user. These would normally have a flag set against system defined values. These could use a WHERE clause to separate the sets.

Hope this is useful.
Simon
Back to top
View user's profile Send private message
jlowry



Joined: 18 Aug 2010
Posts: 3

PostPosted: Thu Aug 19, 2010 5:51 pm    Post subject: Re: Reply with quote

David Atkinson wrote:
1. In terms of limiting what to synchronize, how would you need to do this? Would you need to explicitly select the records within a table that you want to source control, or would you need to use a WHERE clause to specify it?


For us, an example would be adding permissions and menu structure for a particular module that we're working on. If I'm working on 2 modules at once, then I need to be able to individually select the rows that need to be checked in on this commit. We like to make our commits as atomic as possible with regards to the issue that's being solved, so if a row in the static table isn't relevant to the issue, then it should be omitted for this check-in.

David Atkinson wrote:
2. If a developer modifies static data records on his own development database that has previously been committed to source control, they need not commit these new changes to source control. Like any change made on the developer's personal development environment, it doesn't go into source control unless the developer commits it. If the developer has changed something just for a test, they will be able to revert back to this afterwards using the 'undo' function.
David


Perfect!
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group