Comments
Sort by recent activity
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...
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
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...
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:
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...
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...
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
Glad to be of assistance :-) / comments
Glad to be of assistance :-)
Since I'm not the only one now, I'd just add that I'd prefer local gathering to remote gathering with a cache (though I could live with the latter) / comments
Since I'm not the only one now, I'd just add that I'd prefer local gathering to remote gathering with a cache (though I could live with the latter)
Another observation. In the example above, the full join would have been something like
ON J.Prefix=L.JobPrefix AND J.ID=L.JobID
ie, the foreign key has two columns. I notice that after I type "ON " sqlprompt offers me two selections : "J.Prefix=L.JobPrefix" and "J.ID=L.JobID". After I type the "AND " the list it offers me is the standard full list of tables in the current database. It would be better if it offered me the list of foreign keys again rather than a full list of tables. In fact, I'm probably missing something here, but why offer a full list of tables at this point at all? Wouldn't it be better to limit it to tables referenced in the query, or at least prioritize them?
Kev / comments
Another observation. In the example above, the full join would have been something like
ON J.Prefix=L.JobPrefix AND J.ID=L.JobID
ie, the foreign key has two columns. I notice that after I type "ON ...