Comments
Sort by recent activity
Update:
I am using options "Disable foreign keys" and "Drop primary keys, indexes, and unique constraints" enabled.
Anyway, yes, if I do not enable to option to drop/recreate indexes it will work. However, if I do enable to drop/recreate indexes then SQL DataCompare should be smart enough to then also drop/create/check the corresponding foreign keys instead of disable/enable.
And the reason I prefer to drop/create indexes is that I regularly insert/update/delete millions of records via SQL DataCompare and I do not want the indexes to be updated for every single insert/update/delete statement and potentially run into issues with unique constraints or unique indexes. / comments
Update:
I am using options "Disable foreign keys" and "Drop primary keys, indexes, and unique constraints" enabled.
Anyway, yes, if I do not enable to option to drop/recreate indexes it will work. ...
Sam:
This seems to be fixed in the latest version, I now see little filter icons to the side of the table names when filters are active. / comments
Sam:
This seems to be fixed in the latest version, I now see little filter icons to the side of the table names when filters are active.
This appears to be fixed via a spinner indicator though it would be nice to rather have a progress indicator and/or table indicator. / comments
This appears to be fixed via a spinner indicator though it would be nice to rather have a progress indicator and/or table indicator.
Sam:
This appears to be fixed in the latest version. / comments
Sam:
This appears to be fixed in the latest version.
Andrew:
Correct, it should go to SQLCompare. And no, I do not want to disable this manually table by table if I deal with 10s or 100s of columns in a variety of tables. This should be an optional flag as you are overriding explicit table/column design choices. / comments
Andrew:
Correct, it should go to SQLCompare. And no, I do not want to disable this manually table by table if I deal with 10s or 100s of columns in a variety of tables. This should be an optional f...
Well, doesn't look like the window location and size is not always retained.
1) Resize from window to full screen and then back to window --> location/size is retained
2) Resize from window to full screen and then back to window, then close and re-open SQL Compare --> location/size is retained
3) Resize from window to full screen and then back to window then back to full screen, then close and re-open SQL Compare --> location/size is not retained, instead SQL Compare starts out as nearly full screened / comments
Well, doesn't look like the window location and size is not always retained.
1) Resize from window to full screen and then back to window --> location/size is retained
2) Resize from window to full...
The issue with my scenario #3 is that it did not retain the rather small window size and the location. Instead, when it switched from full screen to windowed, the window size was nearly identical to the full screen size 9 (off by a couple of pixels) and the window was centered. This is on a 3-screen system, all screens at 1920x1200 using v12.0.33.3389 / comments
The issue with my scenario #3 is that it did not retain the rather small window size and the location. Instead, when it switched from full screen to windowed, the window size was nearly identical t...
Sam:
This appears to be fixed and deployment script generation also seems to be running a bit faster. / comments
Sam:
This appears to be fixed and deployment script generation also seems to be running a bit faster.
Matt:
Thanks for the reply. May primary issue is that the deployment script get unnecessarily large if you're synchronizing large tables. I regularly sync 100,000+ or even millions of records in our DEV/QA data warehouse environments. Regarding the argument that the target may have changed, then we're having a bigger issue with the synchronization tot he target as the sync itself may no longer be valid. / comments
Matt:
Thanks for the reply. May primary issue is that the deployment script get unnecessarily large if you're synchronizing large tables. I regularly sync 100,000+ or even millions of records in ou...