Comments
Sort by recent activity
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...
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...
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).
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.
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.
Sounds like this issue.
If so, it's a known problem to be fixed in 5.2
Marc / comments
Sounds like this issue.
If so, it's a known problem to be fixed in 5.2
Marc
Brian,
I have sent an email to support referencing this thread.
I didn't realize that I needed to do for this problem to receive direct attention.
My apologies.
Marc / comments
Brian,
I have sent an email to support referencing this thread.
I didn't realize that I needed to do for this problem to receive direct attention.
My apologies.
Marc
Disabling NETBIOS over TCP/IP on the share computer seems to be showing good results. I am a second round of backups and no failures so far.
I would prefer not keeping NETBIOS disabled, as I have to retool various portions of my network to handle that. So, please don't abandon the problem.
I also checked again, and the second machine that was still failing after I disabled Windows Update... well, I guess I didn't disable it. I thought I did... I checked and I did, but when I checked this morning, it was running. And no.. the system didn't reboot.
So, the one machine I'm sure I did disable the Windows Update service did manage to complete the backup.
Does anyone know if the Windows Update service operates on an hourly schedule from boot?
Marc / comments
Disabling NETBIOS over TCP/IP on the share computer seems to be showing good results. I am a second round of backups and no failures so far.
I would prefer not keeping NETBIOS disabled, as I have ...