How can we help you today? How can we help you today?
Mark J
Ok, I've managed to reproduce this now (reference SDC-2206). I'll try and see what we can do to reduce memory usage in the deployment wizard / comments
Ok, I've managed to reproduce this now (reference SDC-2206). I'll try and see what we can do to reduce memory usage in the deployment wizard
0 votes
Hi there - Sorry to hear you're having a bad experience with v12. I'll have a look and see if we can reproduce the same problem locally / comments
Hi there - Sorry to hear you're having a bad experience with v12. I'll have a look and see if we can reproduce the same problem locally
0 votes
We've had a look at this problem, but haven't been able to reproduce it locally - we'll keep investigating and ask if we can think of any more details that would be helpful / comments
We've had a look at this problem, but haven't been able to reproduce it locally - we'll keep investigating and ask if we can think of any more details that would be helpful
0 votes
We've opened a support ticket for the Migrations issue - hopefully we'll be able to get that sorted out too / comments
We've opened a support ticket for the Migrations issue - hopefully we'll be able to get that sorted out too
0 votes
ElliotRodriguez wrote: I am using SQL Compare instead, and side note - I still do not understand why, if SQL Compare fails a deployment, Roles and Users are not part of a rolled back transaction. I received an error deploying from SQL Compare, because DTC was not running, and after I toggled it on and ran the same deployment script, I got another error complaining of a User that was already created. How can a failure not roll back the entire database to the same state it was in before the failure? This has been a long standing issue and I really wish it were addressed (or at least explained). I'll try to get someone to look at the migrations issue since I don't know much about that unfortunately. About the users/roles thing - we rely on a transaction to roll back changes if things go wrong, and according to the code I'm looking at the problem is that adding/removing users from a role isn't allowed inside a transaction. Since we have to create users and roles before we can add users to roles, and since we have to add users to roles before we get to start the transaction, all those things end up happening before the transaction starts. However, from some quick experiments on our test servers, it seems like this might only be a SQL 2000 limitation with sp_addrolemember and sp_droprolemember. Since we're removing SQL 2000 support in v12 we might be able to revisit this and get users/roles inside the transaction. I'll make a note to investigate futher / comments
ElliotRodriguez wrote: I am using SQL Compare instead, and side note - I still do not understand why, if SQL Compare fails a deployment, Roles and Users are not part of a rolled back transaction...
0 votes