Several important issues

freddy12345

HI,

First, a compliment. I love your products, and we have all of them.

I've just begun using Data Compare in 'earnest' and wanted to bring a few points up, to see if there's something i'm missing. Or if we can get some improvements.

Regarding the generated scripts:
1. In strange contrast to Sql Compare the scripts have no Print statements to trace what the script is doing at each point.
2. Also in contrast to Sql Compare, although there is a 'begin transaction' at the start and 'commit tran' at the end, there are no intermediate codes to trap for problems and back things out if problems crop up.
3. also in contrast to Sql Compare, when i run my 200,000 line sync script, after 1/2 minute or more, i get 'query completed with errors', and NO messages in the output window! and no indication of whether changes were actually committed or not. it seems i have to hunt thru every set of changes to see if they got made.

4. On another point (this probably has come up before). there is no way to Save project changes prior to running the data compare. There is a cancel button but no save. The Red Gate programmers are so smart, i am stunned how this basic, crucial, feature could have escaped them!

5. we spent a couple of hours selecting tables and inserting Where clauses. if we got a Where clause wrong and started the Compare, the application crashes and we lose all our work. along with a Save function, it would be great if the Where clause could be tested, or at least if the app would not crash so ungracefully.

6. Finally, looking thru the list of tables to be compared, i noticed some views showing up. why would that be???

Thanks for listening, and i look forward to seeing if there's anything i'm missing here.

Fred

David Atkinson

Hi Fred,
I'm glad you like our products. The feedback you have provided is extemerly valuable to us - Thanks. I'll try to respond to each line item as best as I can. Please feel free to respond to my comments.
1) We made a decision to avoid Print statements for performance reasons so the lack of consistency with SQL Compare is an intentional one.
2) To avoid the possibility of being left in an inconsistent state, we will back out completely if a problem arises.
3) This is either a bug, or the target database has changed since the script was generated. If you can provide us with an example of where/how this fails, it would be most useful.
4) You're right, we've had this feedback before! We acknolwdge that it's definitely not ideal. The project saves itself automatically but only after a successful 'compare'. This is the same with SQL Compare.
5) Crashes should not happen. If you can provide us with a way of reproducing this at our end, we'll look into it.
6) In many situations it is possible to synch views, which will synch the underlying tables, so they are supposed to be listed. However, if both the views and associated tables are selected for synchronization, the synch will fail, so currently you will have to unselect the views. Maybe a better solution would be to have views deselected by default? Let use know your thoughts.

Best regards,

David Atkinson
Product Manager
Red Gate Software

freddy12345

Hi David,

Thanks for your responses.

1) We made a decision to avoid Print statements for performance reasons so the lack of consistency with SQL Compare is an intentional one.
--> it's not clear to me how a print statement would degrade performance. the visibility of how far it's gone is to me far more important than a couple more seconds of execution time. as pointed out in point 3, we're not getting any output messages.

2) To avoid the possibility of being left in an inconsistent state, we will back out completely if a problem arises.
--> the sql compare product has some if checks at the edn, and gives a message as to what happened (kind of, that message could be clearer.) when i look at the data compare synch script, it has a begin tran at the start, and a commit tran at the end. if there is a problem with an intervening insert statement--what does it do? keep going, or stop? in either event, i don't see how you do a back out if a problem arises. how do you trap for a problem?

3) This is either a bug, or the target database has changed since the script was generated. If you can provide us with an example of where/how this fails, it would be most useful.
--> i could send you my synch script, if that would help. even if the target DB has changed, i'd think you'd want a more graceful way to indicate this, than no messages at all.

4) You're right, we've had this feedback before! We acknolwdge that it's definitely not ideal. The project saves itself automatically but only after a successful 'compare'. This is the same with SQL Compare.
--> i'd love to see a 'hotfix' that puts a Save button on the form. you already have the cancel and run buttons, i imagine it should be fairly easy to give us a save. Thanks for considering this.

5) Crashes should not happen. If you can provide us with a way of reproducing this at our end, we'll look into it.
--> i am able to cause a crash pretty easily -- in the where clause, just enter it incorrectly. e.g. instead of pk in (1,2,4,5), leave out the 'pk'. if that doesn't do it for you, let me know and i can supply more info.

6) In many situations it is possible to synch views, which will synch the underlying tables, so they are supposed to be listed. However, if both the views and associated tables are selected for synchronization, the synch will fail, so currently you will have to unselect the views. Maybe a better solution would be to have views deselected by default? Let use know your thoughts.
--> yes, i think views should be deselected by default. ideally, maybe you could provide user with notice of redundant selections, or even disallow them. might be more complex, but certainly useful. maybe views could be visibly represented in a different way? (separate section).

thanks for listening,

Fred

richardjm

I've been asked by David to respond as I'm the guy who's responsible for large parts of the engine of data compare...

1) Some scripts can be very large and take a long time to execute. If I did put in print statements say every 10 changes or say each table completed it could still add up quite quickly and there there would be as many people saying take out all those annoying print statments so it'd have to be an option. We can do it technically just finding a granularity that all can accept it the hard bit.

2) We treat the data transfer as an all or nothing, far better than having some tables migrated and others not. Say you have a reference to another table but no foreign key (it happens - a lot) we migrate the data table but fail to migrate the lookup table and the whole database starts to throw strange errors. Better to just fail and let the use figure out why the synchronization failed as they know their database far better than we could. Possibly better error checking could be integrated into the script but again this is a speed issue bear in mind some people are doing synchronizations that take several hours so adding anything would slow them down considerably.

3) If your target database has changed since you compared then you're using the wrong product. Much better to use the toolkit and have full control over when and how the scripts are generated. We're looking into another possible tool which may address this in the future.

4) I'll leave that for the UI guys.

5) We'll look at that where clause but it's a powerful feature that you can easily shoot yourself in the foot with

6) Views are selected by default because in v4 and prior they were selected by default and we didn't want to change behaviour for v5. You can easily turn off indexed views in the options so they don't appear.

Hope this helps.

Richard
(I feel like I've responded to six forum posts in one forum post )