Comments
Sort by recent activity
Hi Dean,
Thanks for your feedback, as you point out the main problem we have with the Lay Out feature is that what is good layout and what isn't is very subjective.
That being said:
1)
dvitner wrote:
Further on, in the fetch statement, there should be a space after commas between the variables:
Ifetch next from tb into @nazwa, @id, @id_woj, @id_miasto ,@ulica, @telefon, @id_branza, @www, @mail, @kod, @numer_pos, @kierunkowy
removed.
I agree with you that this is an issue that should be addressed...
2)
dvitner wrote:
Notice how that "AND @id_woj is not NULL" got broken into two lines.
removed.
...and this too.
3)
dvitner wrote:
It would be nice if the non-necessary parens were removed.
SQL Refactor's Lay Out feature will not remove unused columns as we felt that most users probably wouldn't expect this to occur. But we are planning a feature which should highlight params and variables that aren't used, this would then allow users to delete them at their discretion. However, in the case of cursors it would rely on users remembering to also remove the unused columns which wouldn't be highlighted. This is an interesting problem you have posed us here.
4)
dvitner wrote:
BTW, guys, is there a way to export my current settings? I believe it would be useful if I could somehow attach the current settings to this post. I can't seem to find where it's written to..
Not yet but I agree that this would be a good idea. Hopefully, we can squeeze it in, but I cannot promise anything.
Many thanks,
Jonathan / comments
Hi Dean,
Thanks for your feedback, as you point out the main problem we have with the Lay Out feature is that what is good layout and what isn't is very subjective.
That being said:
1)
dvitner wr...
Hi Liz
If you are comparing encrypted and unencrypted objects enabling the WITH ENCRYPTION option should make unencrypted objects identical to the encrypted objects if there are no other differences in the object. I have tried this out and unfortunately haven't found the problem you describe. If it is possible can you email some example SQL to jonathan [dot] watts [at] red-gate [dot] com so we can take a deeper look into the problem.
Regards,
Jonathan / comments
Hi Liz
If you are comparing encrypted and unencrypted objects enabling the WITH ENCRYPTION option should make unencrypted objects identical to the encrypted objects if there are no other difference...
Hi there,
Using the rename option in Enterprise Manager or Management Studio calls the sp_rename system stored procedure under the hood. Unfortunately, sp_rename does not rename the object definition in the syscomments(SQL2000) or sys.sql_modules(SQL2005) tables so causes this inconsistancy that you are seeing in SQL Compare.
For further details on sp_rename see this blog article: http://blogs.red-gate.com/blogs/andras/ ... 0/783.aspx
Admittedly SQL Compare could handle this slightly better than it currently does, however the behaviour is essentially an artifact of the slightly bizarre behaviour exhibited by SQL Server when sp_rename is used. Under these circumstances the best practice I'd recommend is to drop and recreate the stored procedure, in fact the sp_rename entry in SQL 2005 Books Online actually states this,
SQL Server Books Online sp_rename wrote:
We recommend you do not use this statement to rename stored procedures, triggers, user-defined functions, or views; instead, drop the object and re-create it with the new name.
Hope this helps. / comments
Hi there,
Using the rename option in Enterprise Manager or Management Studio calls the sp_rename system stored procedure under the hood. Unfortunately, sp_rename does not rename the object definit...
mzcopea,
Okay I will try to explain what is going on:
By using the /options flag you are overiding the default options one of which is "include dependencies".
Will usually suggest that this option is enabled to ensure that scripts don't fail because there are missing objects. This option always ensures that objects required by other objects are scripted and will pull in any dependent objects even if you have excluded them.
For example, A sp_adduser statement for your developer would be pulled into the script if you enabled this option because they have a permissions on objects.
Therefore you are probably right to disable this option.
Enabling the ignore permissions should remove the error, however if there are differences in permissions of users that that you have set up for your production database then these will not be migrated.
So your script should look like this:
sqlcompare.exe /snapshot1:\d:\snap\namesnap.snp /server2:servername /database2:dbname /exclude:user /exclude:role /scriptfile:D:\scripts\Test\TestSynchronizationSql.sql /force /options:forcecolumnorder,ignorewhitespace,IgnorePermissions / comments
mzcopea,
Okay I will try to explain what is going on:
By using the /options flag you are overiding the default options one of which is "include dependencies".
Will usually suggest that this option ...
mzcopea,
Can I ask you what your command line string is, or for the contents of the xml argument file? Then I maybe able to come up with some suggestions for fixing your problem.
Many thanks,
Jonathan / comments
mzcopea,
Can I ask you what your command line string is, or for the contents of the xml argument file? Then I maybe able to come up with some suggestions for fixing your problem.
Many thanks,
Jonathan
Hi there mzcopea
Can you please verify that the developers exists in the target system?
Also I am assuming that you have disabled the include dependencies option to get this error?
If you wanted to avoid permissions being scripted there are the "ignore permissions" and "ignore user permissions and role membership" options which may help you.
Adopting a role based permissions system may also assist you in getting around this issue.
Thanks
Jonathan / comments
Hi there mzcopea
Can you please verify that the developers exists in the target system?
Also I am assuming that you have disabled the include dependencies option to get this error?
If you wanted to...
Hi Mike,
Thanks for your post. I have just tested this on SQL Compare 5.0 and 5.1 with a table where the only difference is the ALLOW_PAGE_LOCKS attribute the of the index. Is it possible for you to post the schema of the offending tables to see if that sheds any light on the problem?
Many thanks,
Jonathan / comments
Hi Mike,
Thanks for your post. I have just tested this on SQL Compare 5.0 and 5.1 with a table where the only difference is the ALLOW_PAGE_LOCKS attribute the of the index. Is it possible for you ...
dvdchas
Rob
Thanks for the feedback, I will try to answer your points as best as possible:
1) The suggestion to have an option to allow you to switch between the old list style and the new grouping style has cropped up quite a few times. I prefer the list style too and we are seriously considering putting this back in for future versions.
2) We made the change in the script colour coding to make it easier to see of differences between lines. However, I can see your point that colouring the entire line as well could help in finding differences. Again this is an area we will look into improving in future versions.
3) Can you check which version of SQL Compare you are using as this has feature has been restored in v5.2.0, in the form of a button on the SQL Difference panel. It is next to the "View T-SQL in groups" check box.
4) As long as users haven't switched off the interactive help then they should be prompted as to what the arrow does, but I agree that there is always room for improvement.
5 and 6) Something like and F11 full screen option? I can definelately suggest it. But I imagine that if we allow users to return to the list view then this will solve most of the real-estate issues.
Regards,
Jonathan / comments
dvdchas
Rob
Thanks for the feedback, I will try to answer your points as best as possible:
1) The suggestion to have an option to allow you to switch between the old list style and the new grouping...
@ Esion and CrispinH
Thanks for the feedback, we have had quite a few comments about the SQL Compare Differences Panel and we do note them all. We may look into improvements such as jump to differences in the next full version of SQL Compare.
Regards,
Jonathan / comments
@ Esion and CrispinH
Thanks for the feedback, we have had quite a few comments about the SQL Compare Differences Panel and we do note them all. We may look into improvements such as jump to differ...
Hi there,
As you suggest unfortunately some of the changes Microsoft made to the SQL 2005 syntax are not compatable with SQL Server 2000, and brackets around the TOP value as one of these changes.
When we migrate a view to a target database SQL Compare uses exactly the same syntax that was used to create the view in the source database. This means that if you are downgrading databases from SQL2005 to SQL2000 then you may experience problems with invalid syntax if you have used SQL 2005 only syntax.
Sorry, I know it must be frustrating, but currently the only way around this situation at the moment is to either:
* Alter your view before you run SQL Compare on it or
* Output the script to QA or Managment Studio and edit there before you run it.
Regards,
Jonathan / comments
Hi there,
As you suggest unfortunately some of the changes Microsoft made to the SQL 2005 syntax are not compatable with SQL Server 2000, and brackets around the TOP value as one of these changes.
...