How can we help you today? How can we help you today?
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 / comments
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...
0 votes