Problema de usuario al conectar a servidor remoto (Windows 7)

[Kammamuri]

Hola.

De antemano gracias al que pueda ayudarme. Les comento.

Se trata de un problema con un programa que hice hace tiempo y que se conecta a una base de datos Interbase 6 (la versión libre). El programa funciona en red y originalmente fue instalado en las siguientes condiciones:
En un servidor Windows 2003 se instaló el servidor de base de datos y al usuario SYSDBA se le cambió la clave por una a la que llamaremos "xyz".
Los puestos de trabajo eran Windows XP (más adelante se agregaron Windows Vista y Windows 7). En la ruta de acceso a la base de datos se especificaba el nombre del servidor y el archivo (nombre_servidor:ruta_de_archivo). Hasta ahí todo perfecto.Ahora estoy intentando instalarlo en una empresa que tiene un grupo de trabajo (no hay servidor) y todos los ordenadores llevan Windows 7. Instalé el servidor en un equipo y cambié la clave de SYSDBA a "xyz". En ese mismo equipo, el programa fuinciona bien. Pero cuando intento que el resto de los equipos se conecten a ese me aparece el conocido mensaje de "Your user name and password are not defined. Ask your database administrator to set up an InterBase login".


Hasta ahora he descartado los siguientes problemas:
Que los equipos no lleguen al archivo de base de datos. Lo sé po que si cambio la extensión del archivo de base de datos. Me dice que no lo encuentra y cuando coloco la extensión correcta me aparece el mensaje de que el usuario y la base de datos no estan definidas.
Que sea un problema de usuario y password. El equipo local accede sin problemas y el programa tiene una única configuración de usuario.He pensado en que sea un problema relacionado con el sistema operativo. ¿A alguien le ha pasado lo mismo o se le ocurre alguna idea?

[duilioisola]

Primero prueba a conectar mediante la IP y no con el nombre del servidor.
Por ejemplo: 192.168.1.1:C:\Datos\BaseDeDatos.GDB
Puede que esté tratando de acceder directamente al archivo y no al servicio de base de datos.
No deberías poder acceder al archivo. NUNCA. La carpeta de datos debe ser invisible al grupo de trabajo.

También asegúrate de que el firewall del equipo que hace de servidor tenga el puerto TCP-3050 abierto (si no has modificado la instalación de Interbase).
Prueba a desactivar completamente el Firewall primero y si es eso ya luego restringes a solo el puerto.

[Kammamuri]

Gracias duiloisola por responder el mensaje, pero te comento:


Actualmente me estoy conectando mediante IP (aunque haya puesto nombre del servidor en la pregunta).
Efectivamente, no accedo al archivo. No está en ninguna carpeta compartida.
Lo del firewall acabo de revisarlo, pero no es la causa del problema. Lo he desactivado en ambos equipos y sigue apareciendo el mismo mensaje.

[duilioisola]

Prueba a poner nuevamene el password a "masterkey". Esto lo realizas mediante GSEC.
Entra en un terminal y luego de ir a la carpeta bin ejecuta gsec.

gsec -user sysdba -pass xyz -mo sysdba -pw masterkey

Ten en cuenta que las claves solo toman los primeros 8 caracteres.

Una vez que tengas la clave master-key prueba a conectarte desde los ordenadores cliente de la forma más simple posible: generando una conexión mediante ISQL.

isql test.fdb -u sysdba -p masterkey


Si esto funciona, prueba primero con claves simples, sin muchos símbolos raros y teniendo en cuenta el máximo de 8 caracteres.

[Kammamuri]

He aplicado los cambios que me comentas y te explico lo que me ha pasado:

En el equipo que hace de servidor he modificado la password a "masterkey" y me he conectado con isql sin problemas. Luego, he ido al equipo cliente y también me he conectado con isql sin problemas. Hasta ahí todo perfecto.

Luego, he vuelto a cambiar la password en el servidor y me he conectado con isql sin problemas. La password que puse no es complicada y de 8 caracteres (son 8 caracteres entre minúsculas y números).

Luego he ido al equipo cliente y no se ha podido conectar. Asi que intenté que se conectara con la password "masterkey" y sí se conectó (???). El equipo que hace de servidor es el 192.168.0.152. Te muestro lo que salió pantallazo:
C:\Program Files <x86>\Borland\InterBase\bin>isql 192.168.0.152:c:\bd\bd.sql -u sysdba -p f46x96hj --> MI PASSWORD ES SIMILAR
Statement failed, SQLCODE = -902
Vour user name and password are not defined. Ask your database adninistrator to set up an InterBase login.
Use CONNECT or CREATE DATABASE to specify a database
SQL>

// AQUI SI CONECTA

C:\Program Files <x86>\Borland\InterBase\bin>isql 192.168.0.152:c:\bd\bd.sql -u sysdba —p masterkey
Database: 192.168.0.152:c:\bd\bd.sql, User: sysdba
SQL> select * from config;
etc...
SQL>No sé que pensar. Supongo que la solución fácil sería recompilar el programa con la pass masterkey por defecto y asunto arreglado...

Por cierto, gracias por tu respuesta

[Kammamuri]

Actualizo la información...

Finalmente, decidí volver a crear el ejecutable, esta vez con la pass masterkey e hice el cambio respectivo en el servidor.

Comprobé que todo fuera bien conectándome con isql tanto desde el servidor como desde el puesto de trabajo. En el caso del puesto de trabajo me decía que estaba conectado a: 192.168.0.152:C\bd\bd.sql.

Ejecuté el programa en ambos equipos e iniciaron sin problemas. Sin embargo, se presentó el siguiente inconveniente: Si hago una modificación en uno de los dos equipos no se ve el cambio en el otro hasta que no cierre y vuelva a ejecutar los programas.

Hice la siguiente prueba:

Ingresé un registro en el programa que funciona en el servidor y y comprobé si aparecía en el cliente con isql y nada. Entiendo que sí se conecta a la base de datos correcta por que, por un lado, la ruta es correcta y por otro, me aparecen los datos que se insertaron en una ejecución anterior. Pero no se actualiza hasta que cierre los programas.

Es como si al abrir el programa cliente trabajara con una copia de la base de datos y luego sincronizara la información al terminar. De hecho, al ingresar datos en una misma tabla en ambos equipos pasó lo siguiente: un generator asigno el 6 al correlativo del programa que corría en el servidor y el 7 al programa cliente. Pero el terminar la ejecución de los programas el registro 6 se eliminó.

[Kammamuri]

Aclaro, por si alguien tiene dudas, que en el objeto TIBTransactión tengo la siguiente configuración:

Params.Strings = (
'read_committed'
'rec_version'
'nowait')


y que hago commit a la transacción:

DataModule1->IBQuery1->Transaction->CommitRetaining();

Por lo que entiendo que no va por ahí el problema.

[duilioisola]

Los generadores en Firebird/Interbase no tienen en cuenta las transacciones. Esto quiere decir que dos sesiones diferentes con dos transacciones diferentes iran obteniendo números de un generador que serán correlativos. Si alguna transacción falla (rollback, exception, desconexión, etc.) el número generado se pierde.

Por lo que comentas, una de las dos transacciones (la que obtuvo el generador 6) ha fallado o se ha hecho un rollback o se ha desconetado y no ha podido grabar sus datos y por eso no ves ese registro.

Lo que comentas de que una aplicación no ve los datos de la otra es por el tema de transaciones. Cada vez que abres la aplicación se abre una transacción. Esta ve todos los datos que se hayan confirmado (commit) anteriores a si misma.
Si quieres ver en una aplicación los datos de otra, deberás cada tanto hacer un commit de la transacción y cerrar y volver a abrir los DataSets.
El CommitRetaining, Graba los datos, pero no abre otra transacción, por lo que seguirás viendo datos viejos.

No se como es la estructura de tu aplicación, pero si la quieres volver multipuesto, deberás ver como actualizar las transacciones.
* Cada vez que abras el formulario.
* Cada vez que grabes un datos, hacer commit y posicionarte otra vez en el registro que correponda al contador (Generador) obtenido.
* Un botón que haga lo que menciono en la línea anterior.

[Efren2006]

He aplicado los cambios que me comentas y te explico lo que me ha pasado:

En el equipo que hace de servidor he modificado la password a "masterkey" y me he conectado con isql sin problemas. Luego, he ido al equipo cliente y también me he conectado con isql sin problemas. Hasta ahí todo perfecto.

Luego, he vuelto a cambiar la password en el servidor y me he conectado con isql sin problemas. La password que puse no es complicada y de 8 caracteres (son 8 caracteres entre minúsculas y números).

Luego he ido al equipo cliente y no se ha podido conectar. Asi que intenté que se conectara con la password "masterkey" y sí se conectó (???). El equipo que hace de servidor es el 192.168.0.152. Te muestro lo que salió pantallazo:
No sé que pensar. Supongo que la solución fácil sería recompilar el programa con la pass masterkey por defecto y asunto arreglado...

Por cierto, gracias por tu respuesta

Amigo por lo leido hasta ahora conoces Bien el procedimiento, solo para tomar en cuenta:

1.- No sera que tu Aplicación tiene busca los datos de conexion en algun sitio y te esta colocando los Parametros Viejos en TIBDatabase ?
2.- Has Probado antes de Hacer la Instrucción TIBDatabase.Connected:=True; .. Ver en un Showmessage(TIBDatabase.Params.Text) a ver que te muestra ...

Todo esto para que salgas de dudas ...