Firebird 1.5.6 y Windows 2008
 

Hola. No consigo que me funcione el firebird 1.5.6 en Windows 2008 32 bits. En principio no hay ninguna restricción para que no se pueda instalar, y de echo el servidor se instala correctamente y en el fichero de log aparece en funcionamiento.
Pero al hacer el gsec para configurar los usuarios siempre da error de base de datos no disponible. tampoco deja entrar con el ibadmin y da el error:
Cannot attach to services manager.

En el firebird.log me aparece:
control services error 1061

He revisado el firewall, antivirus y todo está habilitado y correcto. No sé que más mirar.
¿Funciona realmente en W2008 o no, esta versión del firebird?
Gracias

¿Has mirado en el administrador de tareas si está funcionando el fbserver?

No tienes instalado interbase en el mismo servidor?
No esta filtrando el firewall el puerto 3050?
Prueba con una version mas reciente (2.0 o 2.1)

Con la versión 2.1 no hay esos problemas. Comprobado.

Hola. Gracias por vuestra ayuda. Os comento:
- Con la versión 2.1 funciona perfectamente, pero por las novedades y diferencias introducidas entre la 2.1 y la 1.5.6, no me interesa usar la versión 2.1.
- El firewall está configurado correctamente. De hecho con la versión 2.1 funciona bien. El problema sólo está con la 1.5.
- No estoy simulateneándo ambas versiones. Cuando he probado la 2.1 he desintalado la otro y viceversa.
- El servicio firebird está funcionando y operativo en la lista de servicios, así como el fbguard. Los he detenido y vuelto a arrancar varias veces y nada.
- He revisado el fichero firebird.conf y repasado los parámetros de configuración.

Nada. Que no es posible conectar. Parece que no puede acceder a la base de datos de seguridad. Ya no sé que más hacer.

Pero... cual es el problema que uses una versión que soluciona ese y otros miles de problemas? no comprendo.
Si la solución es mas que sencilla, para que te la complicas?

Pues la versión 2.x introduce una serie de inconvenientes que ahora mismo no es el momento de ponerme a cambiarlos. Entre ellos:
- Cambio en el sistema de alias en las SQL, que obliga a que o bien todas las tablas tengan alias, o ninguna lo tenga. Tengo muchas SQL con tablas con y sin alias. Si se ejecuta en el 2.x algunas dan error y ahora mismo no puedo ponerme a revisar toda la aplicación para cambiarlo. Esto funcionaba perfectamente en la 1.5.6 y ahora en la 2.x da errores.
- No se puede modificar algunas cosas de la estructura de una base de datos en el 2.x si hay otros usuarios conectados. Por ejemplo, utilizaba un sistema para crear tablas "temporales" (simuladas) que en realidad son tablas cuyo nombre es con un generador aleatorio, y cuando se terminaba su uso se borraban. Con el 2.x se pueden crear pero después no se pueden borrar.

Estas cosas entre otras, que en el futuro tendré que cambiar para pasarme a la 2.x, pero que ahora mismo no es el momento para dedicarlo a ello. Por eso necesito instalar la 1.5.6.
Un saludo

A que te referis con ALIAS??? a esto??:

Código SQL [-]
select IDCLI as IDCLIENTE from CLIENTES

Si es asi, tenes en algún otro lado un error, porque tu afirmación es errónea.

Si no las podes borrar es porque el usuario que estaba usando esa tabla , la sigue usando, por lo cual FB te esta protegiendo de un error terrible, que acaba con corrupción de la base de datos con el tiempo.
Te funcionará en la versón 1.5.6 pero esta muy mal, no lo hagas mas porque vas a perder tus datos tarde o temprano.

En realidad creo que deberías agradecerle a la nueva versión, te esta mostrando errores en tu código que te van a traer muchos problemas.

Saludos

Desde luego, lo de los alias sigue igual, se pueden usar o no usar, como se quiera.
Y lo segundo, de ser cierto, menos mal que funciona bien en la 2.1

Gracias por tu contestación, pero no estoy del todo de acuerdo con lo que indicas.

Esta consulta funciona perfectamente en 1.5.6 y en 2.x no:
Para solucionarlo hay que cambiar los ARTICULOS. por A., o quitar el alias A y poner todo como ARTICULOS. No veo que esta consulta esté mal por ello, pero si sé que en el 2.x no funciona. Tuve que investigar el motivo y era simplemente ese. O se usa un alias en todo o no se usa en ninguno, pero no se puede a veces si y a veces no en la misma consulta. No entro a valorar si es correcto o incorrecta formalmente la SQL. Lo cierto es que en el 1.5 funciona bien y en el 2.x no.

Respecto a lo segundo, no veo porque el hecho de crear o borrar tablas en una base de datos tiene porque corromperla. Para eso está la base de datos y sus instrucciones de creación y borrado. No me parece un motivo para ello y no estoy de acuerdo con esa afirmación de que por ello voy a corromperla.
En la versión 1.5.6 no hay tablas temporales, así que si necesito una tabla en la base de datos para un proceso que se ejecuta en un procedimiento almacenado (por ejemplo), lo que hago es crear la tabla con un nombre TMP+código de un generador. La utilizo en el proceso que se quiera y luego cuando ya no se necesita, se hace el drop. No veo que problema o cosa mal esté haciendo por ello como para que se corrompa la base de datos. De hecho, llevo mucho tiempo usando ese sistema y nunca se me ha corrompido la base de datos.

De todas formas, agradezco tu interés y ayuda. Como verás el problema es que necesito usar la 1.5.6 y no veo porque no funciona en el WS2008. Es muy raro.
Un saludo.

sur-se, me he permitido ajustar el código para que se vea completo en pantalla, espero que no te moleste.

Ahora si me queda claro, pense que te referias a que en distintas consultas, en algunas de ellas podias usar alias y en otros no.

Te entiendo, y si realmente nunca vi una consulta donde se use un alias en algunas referencias y en otro no, habria que ver que dice la norma, pero para mi esta pesimamente escrita, prestandose a confusión de quien la lee.

Nunca dije que CREAR una tabla sea para corromperla.:eek:
Lo que te dije es que si FB 2.1 esta EVITANDO que la dropees implica que sigue estando en uso, por tanto TU CODIGO esta mal escrito dado que intentas DESTRUIR un recurso(la tabla) mientras esta en USO. Lo mismo te pasaría con cualquier recurso, objeto, etc, como bien sabes.

Si fuera asi como lo mencionas no habria problemas, si muestras el código te muestro con gusto donde esta el error que causa que FB 2.1 no permita borrarla.

Para eso no tengo solución la verdad, aunque dado el tiempo que paso desde que liberaron la obsoleta v 1.5.6 y el 2008... Como sabes la compatilibidad esta hacia atrás, hacia adelante solo puedes esperar que sea compatible. ;)

uf... se me cruzaron las respuestas: Gracias por editar la consulta para que se viera completa. Muchas gracias.

Um... no veo que esté "pésimamente" escrita por el hecho de escribir en algún sitio ARTICULOS. en vez de A.. Pero da igual, es cuestión de opiniones. No voy a entrar en eso. La cuestión es que no funciona. Quizás no me expliqué antes bien. Pero lo cierto es que en 1.5.6 funciona bien y en 2.x no.

Respecto a lo de la tabla el proceso te lo puedo decir fácilmente:
- Creo la tabla y commit.
- Acceso a la tabla, proceso y demás y commit.
- Drop de la tabla y commit.

Todo en el mismo sitio. No pueden haber dos a la vez, ni la tabla abierta ni nada parecido pues es una tabla de "un solo uso". En este foro se ha comentado varias veces esta opción como solución para las tablas temporales. No es invento mío. Y funciona bien y nada de corromper la BD.
De todas formas, esto último es lo que menos me preocupa. El tema está ahora en tener que revisar toda la aplicacion, todas las consultas para arreglarlas. ahora no es el momento ...
Gracias por tu ayuda.

Hola.

¿ Para la conexión utilizas el protocolo local o de red ?.

Puesto que el protocolo local no te va a funcionar en Windows 2008. En este caso la solución es tan sencilla como pasar a utilizar el protocolo de red, lo cual se consigue simplemente añadiendo localhost: al principio de la cadena de conexión. Naturalmente necesitas abrir el puerto 3050 en el firewall local.

Saludos.

Precisamente es algo que han solucionado en firebird 2.1, si declaras la tabla ARTICULOS con el alias A, es para usarlo, no para luego usar ARTICULOS.
O sea, en firebird 1.5 funciona porque no comprueba correctamente ese error.
Como bien dices, sustituyendo ARTICULOS por A, funciona. Y es que debe ser así. No debería funcionar en la v1.5 pero ya lo han solucionado y es por eso que sí te avisa en la v2.1

Con FIB 2.1 funciona tal cual, sin ningún cambio, o sea que...

Lo que esta mal es que usas ambos. No te ofendas.

Esto tiene mil variantes depende de que componentes uses, como te conectes, en fin, uno nunca ve los errores en su código, por eso me ofrecí a darte una mano.

uff.. no me ofendo, es sólo una opinión y en cierto sentido la comparto contigo, que debería estar todo como A, y mucho menos me voy a enfadar con una persona que está tratando de ayudarme, ni mucho menos ... gracias una vez más.
Cuando descubrí la causa hace tiempo ya me preocupo de poner bien los alias, pero claro hay código antigüo, mucho del cual ni siquiera escribí yo, que puede contener estos errores.

Uso los componentes FibPlus 6 y Delphi 5. Creo la tabla con una instrucción CREATE TABLE y su commit posterior. Hago uso de la tabla y su commit correspondiente. Luego el drop de nuevo. A ver si preparo un pequeño ejemplo y lo subo para que lo veáis.

Un saludo amigos

¿ O sea que, qué ? :confused: :confused:

El protocolo local de Firebird (IPC) dejó de funcionar en Windows 2000 Server, Vista, etc. ... debido a que el mecanismo de comunicación entre procesos del cliente y el servidor Firebird pasó a quedar bloqueado por el sistema operativo.

Precisamente por eso en Firebird 2 programaron un nuevo protocolo local (llamado XNET). Es por eso que Firebird 2.1 te conecta sin cambios, pero eso nunca lo vas a conseguir con Firebird 1.5 que utiliza el protocolo local antiguo (IPC).

Pero te vuelvo a indicar que la solución es tan sencilla como pasar utilizar el protocolo de red (usando una referencia a localhost o 127.0.0.1 como nombre de servidor).

http://www.ibphoenix.com/main.nfs?a=...rebird20_info2

Saludos.

Justamente es el caso opuesto, en este caso dejo de funcionar con una versión previa (win98) no con una versión posterior (win 2000 o superior) por tanto si esta usando IPC debería funcionar de igual manera. De ahi mi "asi que"...;)

No hombre, estamos hablando de Windows 2.008 y no de Windows 98.

Eso creo, al menos.

Saludos.

Tenes toda la razón , se me cruzaron los cables mal. me confundí con otro post de DA! :P

Hola.
No, puede ser el problema el protocolo de red que indicas (IPC vs XNET), pues la cadena de conexión que utilizo es de la forma <nombre del servidor>:<ruta local a la base de datos>. Los equipos que están en red no conectan con la base de datos tampoco. Es decir, ni desde el propio servidor (con localhost o con el nombre de red) ni desde los equipos cliente.
Ahora bien, cambio a 2.1 y si funciona sin cambiar nada en los equipos clientes. Inexplicable.
Un saludo.

Hola.

Ya me parecía a mi que el código de error no se correspondía a ese problema, aún así es lo primero que se viene a la cabeza en un Windows con servicios de Terminal.

Googleando ese error, parece ser que en lugar de localhost tienes que usar la dirección IP (supongo que se refiere a eso cuando habla de node address).

http://tech.groups.yahoo.com/group/f.../message/54779

Pruébalo.

Hola. Normalmente el servidor lo suelo dejar dedicado, como es este caso, por lo que no se trabaja en él. La cadena de conexión que utilizo siempre es <nombre del servidor>:<ruta local a la base de datos>.
En el propio servidor también he probado así, es decir, como si fuese una conexión de red.
La cuestión es que no conectan ni los equipos de la red ni desde el propio servidor con esa cadena de conexión. No suelo utilizar lo del localhost salvo excepciones.
Ahora bien, desinstalo 1.5 e instalo el 2.x y ya funciona bien todo. La misma aplicación, con la misma cadena de conexión.
El cortafuegos está abierto por ese puerto (3050) y el remoto (que lo fijo en el firebird.conf). De hecho, si no fuese así tampoco funcionaría el 2.x.
No sé que más mirar.
Un saludo.

Ya sé que parece una tontería, pero para descartar lo que dice Helen Borrie en ese hilo, ¿ puedes probar usando la dirección IP en lugar del nombre de servidor ?.

Ejplo.: 10.0.0.125:C:\Datos\CLIENTES.DAT

Por cierto, el "Cannot attach to services manager" parece que indica que el Servidor no ha arrancado en absoluto.

¿ Puedes ir al panel de control, herramientas administrativas, Services, y comprovar que el servicio Firebird Server esté arrancado ?, además, como prueba adicional, paralo un momento y a continuación arrancalo manualmente. A ver si arranca bien o da un error (como también parece indicar el "control services error 1061" del Firebird.log).

Por si sirve de algo...
Acabo de mirar un cliente que recordaba que tiene un servidor Win2008.
Tiene la versión Firebird 1.5.2 funcionando.
Puede hacer backups y restores correctamente.
Puede conectarse con IBExpert
Puede conextarse con su aplicación.

SOLUCIONADO !!!!

..... bueno, pongo la solución, evidentemente. Pero primero que nada gracias a todos por vuestra ayuda.

El problema era una tontería. Yo ya me lo imaginaba .... Si es que por estas cosas yo siempre prefiero servidores linux con CentOS ...

Pues bien, en windows 2008 cuando se instala el firebird lo hace en c:\Archivos de programa\Firebird\Firebird_1_5 (en la versión en Español).
Por el nuevo sistema de rutas para los programas, realmente es c:\Program Files.
Esto parece una tontería, pero resulta que la versión 1.5.6 no es capaz de gestionar bien esto nuevo y no consigue acceder a la base de datos security.fdb.
El resultado es que no entra nadie porque no se puede acceder a la base de datos de usuarios. He editado el fichero firebird.conf para cambiar el rootdirectory y ponerlo fijo a c:\Program Files\Firebird\Firebird_1_5 y ahora si funciona.
He podido crear los usuarios de la base de datos y ya todo funciona bien.
Una tontería, ya lo sé, pero tenía que funcionar...
Ahora puedo ir tranquilamente adaptando la aplicación al 2.x (bueno corrigiendo los errores de los alias) y demás.
Un saludo

Hola...

¿Ya probaste usando la IP del servidor en la cadena de conexión? Si funciona podría ser que necesitas hacer que a tu servidor lo puedan ver las otras PC's de la red, esto es, en el "Centro de redes y recursos compartidos" de W2K8 hay una opción que indica si las otras PC's de la red pueden ver a tu servidor.

Yo tenía un problema similar, no podía conectarme a un servidor vía su nombre pero si por su IP, activé esa opción y poblema solucionado...



Saludos...

Vaya... por no refrescar la página antes de contestar mi sugerencia llegó demasiado tarde xDDD

No lo entiendo, en español es "Archivos de programa" y en inglés es "Program Files", pero eso nunca ha sido un problema para firebird :confused:

Hola. No en XP y anteriores. En Windows 7 y en WS2008, realmente es c:\Program Files y para cada idioma se mapea a c:\Archivos de programa o el que sea en otros idiomas. Más o menos eso me parece, no soy ningún experto en Windows.

Realmente el sistema operativo entiende c:\Program Files, porque de hecho cuando se instala la aplicación te pone c:\Program Files\Firebird\Firebird_1_5 y no C:\Archivos de Programa\Firebird\Firebird_1_5 como ocurría en XP o anteriores.

Quizás algún experto en WS2K8 pueda ilustrarnos sobre ello, pero lo que si te aseguro que ha sido cambiar eso y ya funcionaba el 1.5.6.

por otra parte, estoy preparando un ejemplo de lo del drop table para ver si tiene solución, ya que salió en el hilo.

Un saludo.

Yo he tenido problemas con esto con Firebird 2 (que es la que uso por defecto) en Windows Vista (imagino que con Win 7, 2008, etc. ... ocurre lo mismo).

Si sobre el servidor accedo en local como C:\Program Files\Prog\Datos.dat, entonces los clientes no pueden conectar como servidor:C:\Archivos de Programa\Prog\Datos.dat.

Todas las máquinas tienen que conectar usando Program Files, o bien Archivos de Programa (que es un symlink a Program Files), pero no se pueden mezclar.

¿ Seguro que te preguntas porqué hago una cosa tan estúpida ?.

Es una herencia del proceso de instalación que creé cuando solo existía "Archivos de Programa". La instalación en los clientes me deja la cadena de conexión en "C:\Archivos de Programa" que es el valor que usaba por defecto en Windows 95/98/ME/XP/... (si uso otra carpeta del servidor, tengo que modificar el ini manualmente). En cambio en el Servidor, como el instalador sabe perfectamente la carpeta donde se realiza la instalación, modifica la cadena de conexión (y la deja en Program Files).

En definitiva, que para evitar estos problemas (y no hacer chapuzas en la instalación de que si el S.O. es uno utilizo una cadena por defecto, y otro, otra cadena), lo que he terminado haciendo es no utilizando para nada la carpeta "Archivos de Programa", y a partir de ahora colgar directamente mis programas de una subcarpeta en la raíz (con lo que también me ahorro muchos problemas de restricciones por seguridad que Vista/7 añaden a lo que se encuentra en Archivos de Programa).

Esas cosas no me pasan porque siempre uso servidores linux :)

je je .. uno de mi opinión ... a mi me pasa igual .. siempre que puedo servidor linux ...

pero hay clientes que se "encasquetan" con el güindous.

Bueno, el tema del borrado de la tabla. No sé si debería ir en otro hilo, pero bueno, como salió aquí, pues a ver si Donald puede ayudarme, o algún otro compañero. Es un ejemplo sencillo sin controles de errores ni similar. Es para que lo veáis.

Coloco en la pantalla 5 botones:
button1 --> conectar con la Bd
button5 --> desconectar de la bd
button3 --> crear un tabla y commit
button2 --> ejecutar proceso de inserts y commit
button4 --> borrar la tabla creada commit

Un label1 para poner un texto.

En pantalla los componentes fibplus:
FIBdatabase para conectar con la BD
una pareja fibtransaction1/fibquery1
otra pareja fibtransaction2/fibquery2

Se conecta con la Bd, se crea la tabla, se ejectua el proceso, se borra la tabla.
Si el servidor es 1.5, funciona bien. Si es 2.x al borrar la tabla da un error de "object metadata in use".
Todo tiene sus commits correspondientes.
En 2.x, después de crear y ejectuar, si desconecto de la bd y vuelvo a conectar ya puedo borrarla.
Un saludo.

¿ Utilizas la última versión disponible de Firebird 2.1 (2.1.3) ?. Parece claro que la tabla queda bloqueada más allá del tiempo durante el que realizas la transacción (y solo se desbloquea al desconectar la base de datos).

Normalmente estos problemas los suelen solventar en las actualizaciones de cada nueva versión de Firebird.

Yo no puedo hacerlo, mi programa lo pongo en tiendas, y lo normal es que haya dos, tres ordenadores de promedio.

Utilizan uno de los ordenadores como servidor y cliente a la vez.

No puedo decirles que añadan un servidor Linux dedicado, así que me toca lidiar con Windows y sus tonterías.

:(

Hola...

Sobre el detalle de las rutas especiales en Windows, el mismo S.O. ofrece funciones para saber cuales son esas rutas.

La mayoría de los generadores de instaladores son capaces de obtener esas rutas no importa que versión de Windows es y desde tus aplicaciones de delphi solo necesitas usar las funciones del API. Busquen información sobre la función: SHGetSpecialFolderPath, a mi me ha evitado muchos dolores de cabeza...


Saludos...