Cuando una PC ha pasado por muchas manos, la misma pierde su identidad. Esto puede sonar extraño, pero es cierto.
Por ejemplo, hace unos días quería configurar el servicio de Replicación en SQL 2005, de mi notebook y al momento de querer crear una nueva publicación, me encontraba con el siguiente error:
|
TITLE: New Publication Wizard ——————————
SQL Server is unable to connect to server ‘NEW-SERVER’.
—————————— ADDITIONAL INFORMATION:
SQL Server replication requires the actual server name to make a connection to the server. Connections through a server alias, IP address, or any other alternate name are not supported. Specify the actual server name, ‘OLD-SERVER’. (Replication.Utilities)
—————————— BUTTONS:
OK —————————— |
Como se imaginaran, mi notebook se llama NEW-SERVER, y el nombre que me proponía el asistente de SQL era OLD-SERVER. Esto me dejo medio asombrado, ya que buscando por todos los lados posibles, mi SQL Server se identificaba a si mismo como NEW-SERVER.
Hasta que recordé que cuando SQL nos da problemas de configuración, recurramos a los SPs de sistema. De esta manera llegue a sp_helpserver. Un stored procedure que nos muestra la información de replicación del Server. Al momento de ejecutar este SP, el resultado que obtenía era el siguiente.
|
name |
network_name |
status |
|
repl_distributor |
OLD-SERVER |
rpc,dist,rpc out,system,use remote collation |
|
XPRTM-BRUNOC |
NEW-SERVER |
rpc,rpc out,use remote collation |
De esta manera pude ver donde estaba almacenado el dato que me traía problemas.
La solución fue bastante simple, simplemente ejecutar sp_dropserver y luego sp_addserver.
|
sp_dropserver ‘OLD-SERVER’ sp_addserver ‘NEW-SERVER’, ‘LOCAL’ |
Luego reiniciamos el servicio del SQL y listo …
A replicar !!!
Saludos.
PD: Una forma fácil de reconocer con que nombre se está identificando nuestro Server es acceder a la variable de sistema @@ServerName.
|
SELECT @@SERVERNAME AS ‘SERVERNAME’ |
El Bruno 
Leave a comment