Shared Filter Rules?

skuhnskuhn Posts: 27 Bronze 3
edited March 6, 2017 9:38PM in SQL Source Control
Hi,
Here is our scenario:
1. A developer links a database to SQL Source Control
2. That developer creates filter rules for certain objects
3. That developer commits the filter rules to our source control through SQL Source Control
4. Second developer pulls the latest code from source control, which includes the filter rules
5. Second developer links the same database (shared model) to SQL Source Control
6. Second developer finds that the filter rules are not in effect

It seems that SQL Source Control is not recognizing that the filter rules are there. However, if Second developer enters a filter rule, SQL Source Control recognizes that there are changes to the filter rules.
Is there some step that we are missing here to ensure that when someone other than the originator of filter rules can have SQL Source Control utilize those rules?

Thanks,
Scott Kuhn
Tagged:

Comments

  • Hey Scott,

    Thanks for contacting us!
    What type of version control system are you using (Git, SVN, TFS)?
    What version of SQL Source Control are you using?

    Thanks!
    Andrew Pierce
    Technical Sales Engineer
    Redgate Software
  • Hi Andrew,

    I'm also having same issue.
    I'm using GIT and Source Control 5.6.1.5788

    Please let me know what else need to be done to filters work on shared model.

    Thanks,
    Imran
    Senior DevOps Engineer
  • I got it working by linking database using others option and then choose Git from config drop down list. But this option is not giving the ability to push my changes after commit from source control tab.
    Senior DevOps Engineer
  • Andrew PAndrew P Posts: 194 Silver 3
    edited June 24, 2017 4:45AM
    Hey Imran,

    Git is a distributed Version Control system - so usually it will not work well with a Shared model.

    Think about it this way if everyone has different local copies of the repository, but they are all working on the same database - which one is going to be correct, the database or the repository?

    The database would be always right - but the repositories will be in different states - so someone could make a change to the database, then someone else could make that change to their local repo - so the history now attributes the change to the incorrect user.

    If everyone was making changes and committing them to their local repositories, they would all have different git histories with duplicate entries with different revision numbers - so your remote git history would be really odd and incorrect making it less meaningful.

    If you are even thinking of using Migration Scripts - they will not even remotely work with this type of a setup because they rely on changes to the database and changes to the repository being directly related. Ordering becomes very important

    So you can hack around this fundamental issue by using the Git command line hooks (like you have done) - but they do not give you the option to push or pull - nor will you be able to view the Git history from SQL Server Management Studio.

    If you must use Git - then you should be using the Dedicated model.
    If you must use the Shared model - then you should be using a Centralized Versioning System such as Subversion or TFS.

    Do let me know if you have any questions or issues with this!

    Warmly,
    Andrew Pierce
    Technical Sales Engineer
    Redgate Software
Sign In or Register to comment.