Error SQLSTATE = HY000

Deja un comentario

Si cuando quieres conectarte a una Base de Datos el Firebird te muestra el error SQLSTATE = HY000 eso significa dos cosas:

  1. Que la conexión no se realizó
  2. Que la Base de Datos a la cual quisiste conectarte no la reconoce como una Base de Datos válida

El punto 2. por ejemplo puede ocurrir si quieres conectarte a un backup creado por el programa GBAK. El backup creado por el programa GBAK no puede ser usado directamente por el Firebird, debe ser restaurado usando también para la restauración al programa GBAK.

El error HY000 ocurre cuando el Firebird encontró el archivo pero no encontró una página de cabecera en él.

Artículos relacionados:

Entendiendo las páginas de la Base de Datos

El índice del blog Firebird21

El foro del blog Firebird21

 

Una tabla para encontrar lo que necesitas

Deja un comentario

Muchas veces sucede que hemos leído algo, o hemos escrito algo, … pero no recordamos donde está. A todos nos puede pasar, nadie tiene una memoria infalible. Pues bien, para ayudarnos a encontrar lo que necesitamos podemos usar a Firebird.

La idea es la siguiente: en una tabla escribimos los datos que nos ayudarán a encontrar la información que alguna vez pueda ser relevante.

Por ejemplo, supongamos que queremos fácilmente buscar y encontrar todo lo referente a Firebird. Para ello, crearemos una tabla llamada FIREBIRD_DOC

FDC01

Captura 1. Si haces clic en la imagen la verás más grande

La columna FDC_TIPINF (tipo de información guardada) puede tener estos valores:

E=Enlace
S=Stored procedure
T=Texto

Y para asegurarnos que ningún otro valor se pueda insertar, nuestro dominio D_TIPO_INFORMACION está definido como:

CREATE DOMAIN D_TIPO_INFORMACION AS
   CHAR(1)
   CHECK (VALUE IN ('E', 'S', 'T'));

Una vez que le insertamos datos a nuestra tabla tendremos algo como esto:

FDC02

Captura 2. Si haces clic en la imagen la verás más grande

 Y si por ejemplo queremos saber como averiguar si un año es bisiesto o no lo es, podemos escribir algo como:

SELECT
   FDC_CONTEN
FROM
   FIREBIRD_DOC
WHERE
   FDC_CONTEN CONTAINING 'BISIESTO'

Como la columna FDC_CONTEN es de tipo BLOB para ver su contenido hay que copiarlo como texto plano. Por ejemplo si usas el EMS SQL Manager debes hacer clic con el botón derecho sobre el contenido de esa columna y luego elegir la opción “Copy cell”

FDC03

Captura 3. Si haces clic en la imagen la verás más grande

A continuación hay que “pegar” el contenido de esa celda en un archivo de texto plano, por ejemplo en el Bloc de  Notas del Windows.

FDC04

Captura 4. Si haces clic en la imagen la verás más grande

 Y listo, nuestro “ayuda memoria” ha funcionado perfectamente.

Conclusión:

Nadie tiene una memoria infalible y ya que sabemos como utilizar una Base de Datos podemos usar ese conocimiento para facilitarnos las tareas de búsqueda de la información.

En este ejemplo, nuestra tabla FIREBIRD_DOC sirve para guardar toda la documentación relevante a Firebird en ella para que cuando necesitemos algo no debamos estar buscando en Internet (el cual no siempre tendremos disponible). Un simple SELECT a nuestra tabla nos permitirá encontrar lo que sea que estemos buscando (por supuesto, si previamente lo hemos insertado en la tabla).

Evidentemente podemos usar esta idea para guardar cualquier tipo de conocimiento que pueda sernos útiles: canciones, películas, libros, revistas, deportes, temas de interés, lo que sea.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

Limitando los derechos de ejecución de los usuarios

7 comentarios

Una tarea muy importante que tenemos cuando administramos una Base de Datos es limitar los derechos que los distintos usuarios tienen sobre ella. De esa manera impediremos que vean o hagan algo que no deberían ver ni hacer.

Ejemplo:

Tenemos un stored procedure llamado MiStoredProcedure el cual hace un SELECT a una tabla llamada MiTabla. El usuario ELIZABETH debe tener el derecho de ejecutar ese stored procedure. ¿Cómo le otorgamos ese derecho?

Intento 1:

   GRANT EXECUTE ON PROCEDURE MiStoredProcedure TO ELIZABETH;

   COMMIT;

Cuando ELIZABETH quiera ejecutar a MiStoredProcedure obtendrá un mensaje de error: “no permission for read/select access to TABLE MiTabla”

¿Por qué el error?

Porque MiStoredProcedure necesita permiso para realizar el SELECT a la tabla MiTabla y no tiene ese permiso.

Intento 2:

   GRANT SELECT ON MiTabla TO ELIZABETH;

   GRANT EXECUTE ON PROCEDURE MiStoredProcedure TO ELIZABETH;

   COMMIT;

Ahora sí ELIZABETH podrá ejecutar a MiStoredProcedure, no tendrá problemas para hacerlo, pero … hay algo que está mal aquí. ¿Lo has descubierto?, ¿qué es lo que está mal?

Lo que está mal es que ELIZABETH podrá escribir por su cuenta algo como:

SELECT
   *
FROM
   MiTabla;

O sea, podrá conocer todo el contenido de MiTabla y eso puede ser muy inseguro. Por ejemplo, si MiStoredProcedure recibe como parámetro de entrada el Identificador de un Cliente y devuelve el saldo de ese cliente, solamente ese dato queremos que ELIZABETH conozca. Pero si tiene derecho de SELECT sobre la tabla CLIENTES podrá conocer todos los datos de todos los clientes (nombres, direcciones, teléfonos, e-mails, etc.) y no queremos que algo así pueda suceder. Puede ser muy peligroso.

Intento 3:

   GRANT SELECT ON MiTabla TO PROCEDURE MiStoredProcedure;

   GRANT EXECUTE ON PROCEDURE MiStoredProcedure TO ELIZABETH;

   COMMIT;

La diferencia con el Intento 2 es que aquí el derecho de SELECT no se le otorgó a ELIZABETH sino que se le otorgó a MiStoredProcedure.

Como ELIZABETH tiene derecho de ejecución sobre MiStoredProcedure entonces podrá ejecutarlo cuando quiera, pero sin embargo si escribe:

SELECT
   *
FROM
   MiTabla;

Recibirá el mensaje de error: “no permission for read/select access to TABLE MiTabla”. ¿Por qué? Porque ella no tiene permiso de SELECT sobre MiTabla. Ese permiso lo tiene MiStoredProcedure, pero no lo tiene ELIZABETH.

Conclusión:

Mantener a los datos seguros y confidenciales puede ser muy importante en muchos casos, si nosotros somos buenos profesionales debemos tomar las medidas de seguridad apropiadas para que ningún usuario tenga la posibilidad de hacer aquello que no debería hacer.

En general, otorgarle a un usuario o a un rol derechos (permisos) sobre una tabla es un gran error.

Los derechos (permisos) deben otorgarse a las vistas y a los stored procedures, nunca a los usuarios ni a los roles.

De esta manera tendremos bien limitado lo que cada usuario puede hacer, y no nos encontraremos con sorpresas desagradables.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21

 

 

Actualización de stored procedures y triggers

2 comentarios

¿En qué momento se actualiza un stored procedure o un trigger?

Tú cambias el contenido de un stored procedure o de un trigger, luego ejecutas el COMMIT correspondiente, y sin embargo parece que la actualización no ha funcionado.

¿Por qué?

Porque la actualización se realiza solamente cuando el caché está vacío.

En Classic eso ocurre al cerrar la conexión actual.

En SuperServer, como el caché es compartido, eso ocurre cuando se cerraron todas las conexiones.

Artículos relacionados:

El índice del blog Firebird21

El foro del blog Firebird21