Comments
Sort by recent activity
For me, the snippets are much more important (and involve much more work) than the aliases.
Regards,
Alex / comments
For me, the snippets are much more important (and involve much more work) than the aliases.
Regards,
Alex
Thanks Guys,
As suggested I am alternating between the versions. And so far I like what I am seeing; especially the time line!
Alex / comments
Thanks Guys,
As suggested I am alternating between the versions. And so far I like what I am seeing; especially the time line!
Alex
1 - Fixed in RC1
2 - Essentially fixed in RC1 by always reopening on the first monitor.
Thanks,
Alex / comments
1 - Fixed in RC1
2 - Essentially fixed in RC1 by always reopening on the first monitor.
Thanks,
Alex
Fixed in RC1.
Alex / comments
Fixed in RC1.
Alex
Fixed in RC1.
Alex / comments
Fixed in RC1.
Alex
Thanks David, yes that solves my problem.
It wasn't obvious to me (and perhaps others) that "Ignore migration scripts..." also controls revision metadata.
Kind Regards,
Alex / comments
Thanks David, yes that solves my problem.
It wasn't obvious to me (and perhaps others) that "Ignore migration scripts..." also controls revision metadata.
Kind Regards,
Alex
Hi David,
Thanks for your quick response.
We are not using migration scripts (yet), I can see how that may change our processes.
But for now the databases are separately under source control, i.e. against different repositories. This is because they are deliberately kept at different release levels: usually (our copy of) production versus UAT versus development. We periodically use SQL Compare to migrate (some or all of the) changes across from dev to UAT and/or UAT to production (and sometimes in reverse direction to revert changes) without wanting to change the repository against which each database is linked. I.e. we want the changes to be applied as if they were done manually through a release or hotfix script.
In fact we use SQL Compare to generate the update scripts for the client's production environment as well. But because the client typically does not source control their databases and frequently scrutinizes the update scripts that we send them, we do not want the source control metadata included in them.
Alex / comments
Hi David,
Thanks for your quick response.
We are not using migration scripts (yet), I can see how that may change our processes.
But for now the databases are separately under source control, i.e. ...
Thanks Marie,
I have replied by e-mail as well to clarify that this is (primarily) about the Comparison Screen, and to a much lesser extent about the Edit Project Dialog.
Kind Regards,
Alex / comments
Thanks Marie,
I have replied by e-mail as well to clarify that this is (primarily) about the Comparison Screen, and to a much lesser extent about the Edit Project Dialog.
Kind Regards,
Alex
I was about to agree with the "Whole Word" suggestion, but I now realise I need to read the manual first. :?
Apparently "Exact match" doesn't affect the "Matches on Text" results. If this is a bug then the rest of this message is probably a waste of time as everything else may be a knock-on.
But if it is intentional then shouldn't there be a separate option for Partial vs Whole Word matches on "Matches on Text"? And wouldn't it be useful if you could restrict the "Match on" subjects if the behaviour of different Match subjects is meant to be different. There might also be a link with this issue:
Column matches for views show the view definition while for tables they show no detail. Perhaps as a result the column matches for views show up when a partial column name is searched for, regardless of the setting of the checkbox. The fact that the "Match on Text" hits also show (always) may be related to this.
Thanks for your efforts,
Alex / comments
I was about to agree with the "Whole Word" suggestion, but I now realise I need to read the manual first. :?
Apparently "Exact match" doesn't affect the "Matches on Text" results. If this is a bug...