can i ignore certain db objects?

A SQL Server Management Studio add-in to source control your database in Subversion or Team Foundation Server.

Moderators: Chris Auckland, David Atkinson, sherr, PhilScrace

can i ignore certain db objects?

Postby merk » Tue Mar 15, 2011 12:36 am

Unfortunately i have a few stored procs which differ from the dev database compared to the production database. So, i'd prefer it if sqlcompare would ignore these, since i absolutely do not want to copy the dev version into the production db.

So i'd like to know if i can tell sql compare to ignore changes - preferably ignore them just when on a specific db. i.e. if sp_mySproc changes, notify me when i an looking at the dev database, but don't tell me when i am looking at the production db.

Thanks
merk
 
Posts: 17
Joined: Thu Jun 15, 2006 8:31 pm

Postby David Atkinson » Tue Mar 15, 2011 7:11 am

You have posted to the SQL Source Control forum. Could you confirm if your question is about SQL Compare or SQL Source Control?

In SQL Compare you can use the Filter panel to exclude objects. You can save the filter settings with a saved project.

This isn't yet possible in SQL Source Control.

David Atkinson
Product Manager
Red Gate Software
David Atkinson
 
Posts: 1124
Joined: Mon Dec 05, 2005 4:54 pm
Location: Twitter: @dtabase

Postby merk » Tue Mar 15, 2011 7:50 am

I am indeed talking about sql source control. Is this something that's going to be added in?
merk
 
Posts: 17
Joined: Thu Jun 15, 2006 8:31 pm

Postby David Atkinson » Tue Mar 15, 2011 4:01 pm

Yes, this is on the roadmap for hopefully later this year. It would help us when designing the feature to understand why you have objects that differ that you wouldn't want to commit to source control.

David
David Atkinson
 
Posts: 1124
Joined: Mon Dec 05, 2005 4:54 pm
Location: Twitter: @dtabase

Postby wtjones » Tue Mar 15, 2011 6:56 pm

The main reason I want this is because we develop our own objects on a vendor-created database and are not as concerned with source controlling their code.

It would not be a huge deal to have then in SC except that we have a large number of objects in the db and I suspect this as the reason for slow performance.
wtjones
 
Posts: 14
Joined: Tue Jan 08, 2008 4:27 pm

Postby merk » Tue Mar 15, 2011 7:49 pm

For me, in this instance, i have linked servers and the server names/db names differ between dev and production. So my stored procs will always be slightly different between dev and production. I couldn't find a way to use some sort of aliasing system so that i could keep the stored procs in sync. So right now i always have some stored procs showing up as needing to be committed, or updated, since they have different linked server names in them.

i also occasionally comment out sections of code in my dev or prod stored procs since some of it's for debugging purposes.
merk
 
Posts: 17
Joined: Thu Jun 15, 2006 8:31 pm

Postby David Atkinson » Tue Mar 15, 2011 8:05 pm

@merk - that's useful information. You're using filtering to ignore known stored procedure differences as a workaround for linked server name references. This is an issue we anticipated, but so far we've not had anyone bring it up just yet. I'd be very interested in hearing from any other users who are experiencing this. Clearly, if this is a pervasive issue, we should be looking at addressing the root cause and devising a mechanism where these different server name references aren't regarded as actual differences.

David
David Atkinson
 
Posts: 1124
Joined: Mon Dec 05, 2005 4:54 pm
Location: Twitter: @dtabase

Re:

Postby merk » Tue Mar 15, 2011 8:31 pm

David Atkinson wrote:@merk - that's useful information. You're using filtering to ignore known stored procedure differences as a workaround for linked server name references. This is an issue we anticipated, but so far we've not had anyone bring it up just yet. I'd be very interested in hearing from any other users who are experiencing this. Clearly, if this is a pervasive issue, we should be looking at addressing the root cause and devising a mechanism where these different server name references aren't regarded as actual differences.

well ideally, it would be nice if i could specific a string that would get auto-replaced when moving from one server to another.

ie on dev it's linkdevserv. DevDb.dbo.devtable
and when i'm pushing changes to the production db, it should automatically convert linkdevsrv to linkprdserv and devdb to proddb, and should ignore differences in that text when doing a compare.

I didn't think that would be something that would be included in sql source control, which is why i asked about ignoring files, which is obviously an imperfect workaround.
merk
 
Posts: 17
Joined: Thu Jun 15, 2006 8:31 pm

Postby David Atkinson » Tue Mar 15, 2011 9:25 pm

Some sort of server name mapping or parameter substitution could maybe used to solve this issue. I expect we'll get an increasing number of questions about this over the coming months. At least you'll have some sort of workaround once we've added object filtering!

David
David Atkinson
 
Posts: 1124
Joined: Mon Dec 05, 2005 4:54 pm
Location: Twitter: @dtabase

Postby jim.whaley » Tue Apr 26, 2011 3:18 pm

We are running into an issue with synonyms.

We have a reporting database that looks at a replicated (MSSQL replication) copy of our production database.

We use synonyms in our reporting database to point to the replicated production database.

I don't really want or need the synonyms in source control. When we deploy a new report database, we simply run a proc that automatically creates all of the synonyms.

Sure would love the ability to exclude things from source control! :-)

Jim
jim.whaley
 
Posts: 1
Joined: Tue Apr 26, 2011 3:10 pm

Postby David Atkinson » Tue Apr 26, 2011 3:29 pm

We're working on adding the same filtering screen you currently get in SQL Compare. This will filter the Commit list to exclude objects you specify. The idea is that the filter is saved as a per-project setting, which means that all users connected to the same repository will inherit the filter.

Comments on this approach are most welcome! As soon as we've got something ready, we'll release this as an Early Access build.

David Atkinson
Product Manager
Red Gate Software
David Atkinson
 
Posts: 1124
Joined: Mon Dec 05, 2005 4:54 pm
Location: Twitter: @dtabase

Postby ahmannj » Wed Apr 27, 2011 9:37 pm

As long as you're looking for feedback... I'd love to exclude Users, Permissions and Role Memberships - since they always differ between our development environment and our higher test and production environments. I'd prefer to exclude them from our source control system, rather than from the sync process during promotion to the higher environments.
ahmannj
 
Posts: 13
Joined: Fri Jan 06, 2006 5:05 pm
Location: Minneapolis, MN. USA

Postby David Atkinson » Thu Apr 28, 2011 3:19 pm

Thanks for the feedback. Let me know if you would like to be added to our SQL Source Control early access notification list? This way you’ll be notified when we have a Beta build to try out, and you’ll have the opportunity to let us know if it meets your needs.

Kind regards,

David Atkinson
Product Manager
Red Gate Software
David Atkinson
 
Posts: 1124
Joined: Mon Dec 05, 2005 4:54 pm
Location: Twitter: @dtabase

Postby ahmannj » Thu Apr 28, 2011 6:13 pm

I'm on the list already - thanks!
ahmannj
 
Posts: 13
Joined: Fri Jan 06, 2006 5:05 pm
Location: Minneapolis, MN. USA

Postby bradtoast » Thu May 19, 2011 1:15 am

Could you please add me to the list? I would also be interested in having the ability to have a config file where I could set variables to be used in creating synonyms that reference other databases where the names might change from environment to environment.
bradtoast
 
Posts: 2
Joined: Thu May 19, 2011 1:07 am

Next

Return to SQL Source Control 2

Who is online

Users browsing this forum: No registered users and 0 guests