Activity overview
Latest activity by marclallen
Oops... I spoke too soon. Using '.' uses the base machine. I'm actually using a specific instance and when I change it for that, it breaks again. Here's the real deal: Essentially, SQL Server 2008R2 does not recognize a loopback linked server for what it really is... self-referencial. So, when you access it, it still opens up a new SPID to it. However, with the transaction started and the first (dummy) proc alteration done, the script SPID has an X-lock on some special, super secret, DAC-accessable only, schema table (sysschobjs). So, when the new SPID tries to verify the linked server table exists, it blocks. So, the script blocks on itself, but doesn't realize it. / comments
Oops... I spoke too soon. Using '.' uses the base machine. I'm actually using a specific instance and when I change it for that, it breaks again.Here's the real deal:Essentially, SQL Server 2008R...
Ok.. the problem seems to be if it uses a linked server that is actually a link to itself. / comments
Ok.. the problem seems to be if it uses a linked server that is actually a link to itself.
Narrowed it down to a single, specific linked server (which happens to link to itself). / comments
Narrowed it down to a single, specific linked server (which happens to link to itself).
Thanks, but I don't think that's the problem. I tried some of the queries from that linked article and don't seem to have any permission issues. It gets stranger. It only seems to happen on the *second* procedure/function that I alter (all within the same transaction) that uses a linked server. If I only try to update one, it works fine. / comments
Thanks, but I don't think that's the problem. I tried some of the queries from that linked article and don't seem to have any permission issues.It gets stranger. It only seems to happen on the *s...
It appears to be due to the overall transaction. Removing it eliminates the issue. But, since it's a deployment script, I really don't want to have to do that. / comments
It appears to be due to the overall transaction. Removing it eliminates the issue. But, since it's a deployment script, I really don't want to have to do that.
Deployment freezes when linked servers are involved
I'm looking for some help here. I don't believe this is a problem with SQL Compare.When I have a number of changes for, say, functions that touch linked servers, when I execute the deploy script (...
git Branch management
Hi!I'm not entirely clear on the best way to handle branches using SC.Once I'm linked, can I just manipulate the repository from behind the scenes and then refresh? Or do I need to unlink, relink ...
Oh... man... never occurred to look there... I assumed it was with all the other options. Thanks! / comments
Oh... man... never occurred to look there... I assumed it was with all the other options. Thanks!
Ok, thanks. I'll look more closely. I'm still pretty new to SQL Compare and it might have flagged the indexes in addition to something else. / comments
Ok, thanks. I'll look more closely. I'm still pretty new to SQL Compare and it might have flagged the indexes in addition to something else.
Controlling Transaction Isolation level for deployment script
When deploying from SQL Compare, the script is wrapped in a transaction with the isolation level set to SERIALIZABLE.When altering or creating a proc that uses a linked server, SQL Server attempts ...