SQL Backup 3.2 on cluster
rdameron
Posts: 13
I've installed SQL Backup 3.2 on to each physical node of a three node MSCS cluster. Each node is running a named instance of SQL Server 2000. The operating system is Windows Server 2003 Enterprise Edition. I have installed the extended stored procedure on each node.
The following error message appears upon startup of SQL Backup on any of our cluster nodes. Also, it appears after installing the extended stored procedure.
SQL Backup
[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
OK
I can click through it and use the product. Any possibility of a patch for this issue?
I believe it is attempting to connect to one of the named instances that is located on another node. I can see all the named instances for the cluster in the left pane. Ideally, I think I should only see the named instance that resides on that node.
The following error message appears upon startup of SQL Backup on any of our cluster nodes. Also, it appears after installing the extended stored procedure.
SQL Backup
[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.
OK
I can click through it and use the product. Any possibility of a patch for this issue?
I believe it is attempting to connect to one of the named instances that is located on another node. I can see all the named instances for the cluster in the left pane. Ideally, I think I should only see the named instance that resides on that node.
Comments
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 8
We have three physical machines (nodes) in the cluster.
There are three named instances in the cluster. Usually, each instance is running on its own node.
If one node has an issue, it fails over to one of the other nodes.
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 8
I am having the same problem and the solution eludes me.
The conclusion is that this is an annoyance in the GUI when running on clusters. SQL Backup tries to connect to every instance of SQL Server that it finds on a machine, and when it fails to connect, an error is raised.
On a regular server, most instances are running so this is not a problem. On a cluster however, there are probably some failover instances on each node, so they are inactive most of the time.
The 'fix' for this in a future version is to not raise these errors so aggresively if running on a cluster.
SQL Backup Consultant Developer
Associate, Yohz Software
Beyond compression - SQL Backup goodies under the hood, updated for version 8