Activity overview
Latest activity by SQLGuru
"Scripts Folder MetaData File Incomplete"
I've just upgraded from 8.0 to 8.1. It seems that the XML file created by SQLCompare when saving a database as a collection of scripts has changed. The file was "SqlCompareDatabaseInfo.xml" and i...
I've emailed one of the procedures raising an error. I'll try to investigate a bit further later today. / comments
I've emailed one of the procedures raising an error. I'll try to investigate a bit further later today.
Problems Reading Scripts - XML
The new Problems Reading Scripts functionality is proving very helpful. In addition to helping me more quickly pinpoint the occasional syntax error checked-in by the devs, the report is pinpointin...
Given the manner in which we cycle through our change management, I will rarely need to compare the same database that I did the last time I opened the application. That said, I can live with one extra click to open and use the app. [image] / comments
Given the manner in which we cycle through our change management, I will rarely need to compare the same database that I did the last time I opened the application. That said, I can live with one ...
I must admit I preferred the version 7 approach to listing projects as well. I've over 40 different databases; hence over 40 different comparison projects -- and that's if I have only one per database. The version 7 comparison projects dialog was visually rich, and also supported filtering. Moreover, when opening a project via Open From Location on Disk with the beta, you must navigate to the correct folder every time -- it doesn't maintain the path. Also, it seems that if you switch to another application and then back to the beta, the Open dialog box doesn't return to the foreground.
EDIT -- I want to also add that with the previous approach I generally only needed to store a single project for a given database. I could compare numerous instances of said database across many environments by changing the source and target servers configured for that project. I could easily identify the database I needed from the project dialog regardless of the servers involved. This is proving difficult with the beta.
EDIT -- I'm trying SaveAs to create project names that exclude servers. / comments
I must admit I preferred the version 7 approach to listing projects as well. I've over 40 different databases; hence over 40 different comparison projects -- and that's if I have only one per data...
I've just started looking at the beta, and the "switch" button is the first thing I've noticed. I didn't mind this over double-clicking the arrow until I noticed that it now requires a re-compare. Some of our databases have thousands of objects; a compare can take a couple minutes. Also, our change management can be fairly complex, requiring selective updates in both directions. / comments
I've just started looking at the beta, and the "switch" button is the first thing I've noticed. I didn't mind this over double-clicking the arrow until I noticed that it now requires a re-compare....
I also have a problem with SQL Compare 6.2 occasionally ignoring files when comparing scripts to a live database. This behavior is misleading -- it implies that the script is no longer present in one's source control, possibly prompting one to drop the object from the live database. I submit that the tool should provide a warning (specifying the files in question) when it encounters .SQL files that it cannot parse. Simply ignoring files is a dangerous oversight. Would it be possible to provide an applet that reports on these files until it can be added directly to a version of SQL Compare? If helpful, I can provide some stored procedures currently ignored. / comments
I also have a problem with SQL Compare 6.2 occasionally ignoring files when comparing scripts to a live database. This behavior is misleading -- it implies that the script is no longer present in ...