En las sesiones de Certificación a3ERP versión 9 para distribuidores de estas últimas semanas, surgió la duda de si la migración de la versión 8 a la versión 9 conservaba usuarios y permisos de la aplicación.

El sistema de migración de v8 a v9 sí garantiza la migración de todos los usuarios de la aplicación así como de los permisos de sus diferentes perfiles, aunque debemos aclarar algunos aspectos a tener en cuenta:

En todas las versiones de la aplicación (desde nexus 4.0.0) ha sido posible cambiar el servidor conservando usuarios, contraseñas, perfiles y permisos de los usuarios.

En la página de soporte del producto http://soporte.websie.com, pestaña documentación, apartado documentación SQL / Otros, existen 2 documentos que explican el cambio de servidor;

El primero de ellos explica cómo hacer un cambio de servidor simple. Con este primer sistema, efectivamente, no se traspasan usuarios ni permisos.

El segundo de ellos, cambio de servidor en modo experto, explica paso por paso cómo traspasar toda la información de usuarios, contraseñas, perfiles y permisos al nuevo servidor.

Resumidamente, el documento explica cómo:

1. Instalar SQL Server en el nuevo servidor
2. Copiar nexus con todas sus extensiones: Programación a medida, diccionarios…
3. Recuperar con la consola de SQL Server todas las bases de datos de la aplicación (NEXUS$SISTEMA incluida).
4. Pasar una vista en la base de datos nexus$sistema para modificar el nombre del servidor en uno de los campos.
5. Pasar inicios de sesión (usuarios de nexus) de un servidor SQL Server a otro procesando unas vistas diseñadas por Microsoft.

En este punto 5, básicamente, hay que procesar una vista proporcionada en la documentación de Microsoft en el servidor orígen. Esta vista genera un procedimiento almacenado en SQL. Cada vez que ejecutamos el sp generado (sp_help_revlogin), el sistema devuelve una vista que hay que procesar en el servidor de destino, generando los logins corrrespondientes.

Como truco, podemos guardar el resultado de este sp_help_revlogin en un fichero de texto cada vez que demos de alta usuarios en nexus / a3erp, de forma que si cae el servidor, al procesar este fichero de texto en otro servidor, se regenerarán los logins, que junto con la copia de seguridad de la nexus$sistema, recuperan toda la configuración del entorno de seguridad de la aplicación.

Con estos pasos, el cambio de servidor para el usuario de la aplicación es transparente.

Este sistema de cambio de servidor es altamente recomendable cuando se haya diseñado seguridad para nexus / a3erp, pero también cuando se hayan diseñado CUBOS en BI. Además el sistema optimiza enormemente el tiempo de migración cuando existen muchas bases de datos en la aplicación, ya que la creación de bd en SQL, el backup y la restauración se pueden ejecutar mediante scripting.

Espero que estos consejos os ayuden a conseguir una mayor eficiencia en vuestro trabajo al tiempo que seguro elevará la satisfacción del cliente final cuando os veáis ante la necesidad de un cambio de servidor.

¡Feliz Navidad para todos !

Se puede dar el caso de que Nexus funcione perfectamente desde cualquier estación, pero Nexus BI sólo funcione desde el servidor. ¿Qué puede estar pasando? Y no es el firewall, ya que Nexus SÍ FUNCIONA…

El problema se debe a un “engaño” del firewall. Efectivamente, si tenemos un firewall iniciado y abrimos el puerto del SQL Server (por defecto 1433 TCP -aunque si hay nombre de instancia varía-), Nexus funciona. Pero para el correcto funcionamiento de NexusBI, en el firewall debemos abrir también el puerto 1434 UDP.

Explicación:

El puerto 1434 UDP es el que usa el servicio SQL Browser, encargado de “publicar” el nombre del servidor SQL en la red. El tipo de conexión que usa Nexus, en algunas ocasiones, no necesita que este servicio Browser esté accesible. En cambio, NexusBI, con una tecnología de conexión a la base de datos más moderno, sí necesita el acceso a este servicio, por lo tanto, SQL Server Browser debe estar iniciado y accesible desde la red.

En todo caso, el documento de la web DbNetLib Connection Open…. soluciona los errores de comunicación tanto de Nexus como de Nexus BI.

Es una “sana” costumbre dotar a los sistemas operativos de antivirus, que en un momento de despiste nos pueden salvar de más de un susto. Pero instalar un antivirus no debería quedarse en el típico proceso del asistente de instalación: “Siguiente… Siguiente… Finalizar”. Sobre todo si nos referimos a la instalación de un software de antivirus en un servidor con SQL Server.

SQL Server es un servicio que “mantiene abiertos” una serie de ficheros en el sistema operativo: sus bases de datos. Cada base de datos de SQL Server se corresponde como mínimo, con dos archivos físicos que se almacenan en disco. Además, estos archivos pueden llegar a ser muy grandes, si las bases de datos guardan mucha información.

Con todo esto, tras instalar un antivirus, debemos excluir del motor de análisis en tiempo real del antivirus una serie de archivos para que el rendimiento del SQL Server no se vea afectado. Estos archivos son los que finalizan con las extensiones: *.ldf, *.mdf, *.ndf, *.bak y *.trn.

Esta exclusión del análisis, evidentemente aumenta el peligro de contagio por virus, por lo que es muy conveniente programar un análisis periódico de estos archivos.

Tranquilidad. Simplemente nos falta solucionar un pequeño detalle:

Cuando Microsoft actualiza SQL Server a una versión posterior, para “curarse en salud” y asegurar que las aplicaciones sigan funcionando correctamente, deja las bases de datos en “modo de compatibilidad” con la versión de SQL Server de la que proceden.

Así, si actualizamos un MSDE (o SQL 2000) a una versión 2005 o 2008, las bases de datos se quedarán en “Nivel de compatibilidad 80″.

Para solucionar esto, debemos acceder a las propiedades de las bases de datos (con Management Studio) y modificar un valor denominado Nivel de compatibilidad. Este nivel de compatibilidad lo estableceremos a ’90′ si hemos instalado un SQL Server 2005 o a ’100′ si hemos instalado un SQL 2008.

¿Y si no tengo Management Studio?

Management Studio es una aplicación gratuita de libre descarga de Microsoft y permite administrar gráficamente servidores de SQL Server 2000 y 2005, pero si no se dispone de la herramienta y hay que proporcionar una solución rápida, se puede escribir lo siguiente en el servidor de SQL (en MS-DOS) y el problema se solucionará:

c:> osql -S [nombredelservidordesql] – U sa -P [password del usuario sa] -Q “sp_dbcmptlevel [nombre de la base de datos], 90*

*O bien 100 si se trata de SQL Server 2008.

- ¿¿¿no sé qué hacer… dónde debo conectarme???    

Pues así es, compañeros… cuando nexus arranca, no sabe dónde conectarse ni cuál es su servidor, y ése es el trabajo del famoso sistema.ini. El problema añadido es que al desinstalar nexus, el sistema.ini NO SE BORRA, y si hay que cambiar de servidor… ja ja… el sistema.ini ENGAÑA a nexus, por lo que es necesario borrarlo.

Pero todos sabemos cómo es capaz de esconderse el “dichoso” fichero. Aquí tenéis unas claves para encontrarlo:

Al arrancar, Nexus busca el sistema.ini en unos lugares por un ORDEN ESTABLECIDO.

WINDOWS XP
      A. Carpeta donde se encuentra el nexus.exe
      B.  La carpeta C:\documents and settings\[nombre del usuario]\datos de programa\sie\sistema
      C.  B.  La carpeta C:\documents and settings\all users\datos de programa\sie\sistema

WINDOWS VISTA
      A. Carpeta donde se encuentra el nexus.exe
      B. La carpeta C:\Users\franciscon\AppData\Roaming\SIE\Sistema
      C. La carpeta C:\Program data\SIE\

Uffffff… ¿Para darnos este tostón escribes, franciscon?…

Y como bueno es el pareado, y no falto de razón,
ahí va el truquillo para no entrar en desesperación:

EN CUALQUIER SISTEMA OPERATIVO,  una forma fácil de encontrar el sistema.ini:

A. En la carpeta de nexus.exe
B. inicio>ejecutar.. y escribimos “%appdata%”
C. inicio>ejecutar.. y escribimos “%allusersprofile%”

Tanto la orden de B como la de C nos llevan a la carpeta SIE, que contiene el sistema.ini, pero también PANTALLAS, GRIDS, PREFERENCIAS…  en fin, útil para buscar el sistema y más cosillas.