Activity overview
Latest activity by kev1609
Thanks Richard, that was my fall back plan but I was hoping there was a simpler solution / comments
Thanks Richard, that was my fall back plan but I was hoping there was a simpler solution
Hi Richard, thanks for coming back to me. Yes, I am using that installer (SQLDeveloperBundle.exe). Running it did upgrade a number of my tools that hadn't been manually updated yet. However, because I already had the most up to date version of SQL Source control installed under the earlier version of SSMS, it didn't allow me to select it for installation. So now I still have it in the old SSMS, but don't have it in SSMS 17.5. How can I get the installer to add it to SMSS 17.5, when it's already installed and fully up to date in the earlier version of SSMS? / comments
Hi Richard, thanks for coming back to me. Yes, I am using that installer (SQLDeveloperBundle.exe). Running it did upgrade a number of my tools that hadn't been manually updated yet. However, becaus...
Add SQL Source control to newly SSMS version
I've just installed SSMS 17.5. Previously was using an earlier version with Prompt, Test, Source Control etc installed. I reran the developer bundle installer, which added most of the tools to the ...
Message "Query was cancelled"
Hi,
Started getting the message "Query was cancelled" against a couple of servers in a group that I use multiscript to update. The queries in question can then be executed directly on the servers, ...
They were added manually early on in development. Our convention is to have a guid column as the first column in all tables on a replicating database, followed by the primary key column(s). As for interfering with anything, no, they're just an additional column that isn't used directly by the applications.
Any other replication objects we are settin up filters for. These we specifically don't have on the dev environment. In the past i've needed to manully uncheck them before doing a sync, which isn't as bad as it sounds as they occur for the most part in contiguous chunks in the output. Having them ignored by a filter is one less thing to get wrong though!!
Kev / comments
They were added manually early on in development. Our convention is to have a guid column as the first column in all tables on a replicating database, followed by the primary key column(s). As for ...
David Atkinson wrote:
With regards to replication, I'm curious about how you're dealing with comparing against tables which have additional MSmerge rowguid replication columns.
Nothing very exciting, I'm afraid. We have a guid column with the rowguid attribute set in all of our tables on both the development servers and the replicated production servers.
Kev / comments
David Atkinson wrote:
With regards to replication, I'm curious about how you're dealing with comparing against tables which have additional MSmerge rowguid replication columns.
Nothing very ex...
Ignore insignificant differences in default values
Hi,
We have some tables where the only differences are similar to those shown below:
Database one:
[Hazardous] [bit] NOT NULL DEFAULT (0),
[Reefer] [bit] NOT NULL DEFAULT (0),
Database two:
[Hazard...
David Atkinson wrote:
Please let us know if this meets your expectations.
I've taken a look at it and it certainly addresses our needs. I'll continue playing and see if I encounter any problems, but it looks good.
One small thing I noticed is that I can no longer double click on the compare direction arrow to reverse the syncronisation. Is this just missing from the beta, or has it gone for good, or has the functionallity just moved elsewhere?
Kev / comments
David Atkinson wrote:
Please let us know if this meets your expectations.
I've taken a look at it and it certainly addresses our needs. I'll continue playing and see if I encounter any problem...
David Atkinson wrote:
You'll be pleased to know that we're considering thinking about improving the object filtering in SQL Compare, although this is penned for no earlier than v7.1.
Can I ask whether where in the SQL Compare process would you like to specify such regular expressions? Can you give me one or more specific examples of the regular expression(s) that you would like to exclude from the object list?
Well, it's largely related to replication at the moment, in that even with the replication triggers option ticked, my comparison still flags things like the replication stored procedures (sp_sel_#######, etc), and views (msmerge_contents_{TABLE}). Clearly you could add these as an explicit replication setting, but it strikes me it would be more flexible to allow the user to specify his own list of filters.
As another example, we have one application which is modular. Some sites will not use certain modules, and consequently don't need us to sync the relevant objects. We have a naming convention to determine which items belong to which module, and a regexp filter would allow us to set up a project specific to each site.
As to how it would be set up, perhaps a section for each type of object containing a list of filters for that type of object. You could then elect to ignore any stored procedure that matches a given filter. Does that make sense?
Kev / comments
David Atkinson wrote:
You'll be pleased to know that we're considering thinking about improving the object filtering in SQL Compare, although this is penned for no earlier than v7.1.
Can I ask w...
In fact, it would be great to have a facility to specify a list of regular expressions and then skip any objects that match those regular expressions / comments
In fact, it would be great to have a facility to specify a list of regular expressions and then skip any objects that match those regular expressions