Evitando que el tamaño de la Base de Datos se incremente demasiado

4 comentarios

Como Firebird usa la arquitectura MGA el tamaño de sus bases de datos puede crecer mucho y muy rápido.

La arquitectura MGA es muy buena para nosotros porque nos permite regresar la Base de Datos a su estado anterior. Cada vez que se modifica o se borra una fila esta arquitectura guarda una copia de la fila original. De esa manera siempre tenemos disponible la última versión de la fila y la ante-última versión de la fila. Y con los comandos COMMIT y ROLLBACK decidimos cual de esas versiones queremos usar.

En algunas transacciones nuestros cambios afectan a solamente una fila, pero en otras transacciones podrían afectar a decenas, miles, o millones de filas. Y gracias a MGA no debemos preocuparnos porque si queremos retrotraer la Base de Datos a su estado anterior, un simple comando ROLLBACK hará la tarea por nosotros.

Pero no todo son ventajas, también MGA tiene sus desventajas. Y es que esas filas que se fueron agregando con cada comando UPDATE o DELETE que ejecutamos van ocupando espacio dentro de la Base de Datos haciendo que se vuelva cada vez más grande. Y al volverse más grande también muchas operaciones se vuelven más lentas. El conjunto de todas esas filas que están dentro de la Base de Datos pero que ya son totalmente inútiles se llama “basura”.

La buena noticia es que podemos eliminar a la basura muy fácilmente. La mala noticia es que requiere de tiempo, no es algo instantáneo. Como consecuencia, lo recomendable es que la basura sea eliminada cuando nadie usa la Base de Datos. Si esto no es posible, entonces se debe eliminarla el día o la hora en que menos usuarios estén conectados (por ejemplo, todos los Domingos a las 23:00)

Entonces, nuestra tarea de mantenimiento tiene 2 partes:

  1. Un ciclo backup/restore
  2. Un barrido de la basura

El ciclo backup/restore nos asegura que solamente la última versión de cada fila se encuentra en la Base de Datos. Por lo tanto su tamaño disminuirá. Y en ocasiones la disminución es asombrosa, una Base de Datos de 350 Mb podría pasar a tener 40 Mb cuando el ciclo finaliza.

El barrido de la basura nos permitirá evitar que el tamaño de la Base de Datos crezca sin control. Si periódicamente hacemos un barrido entonces siempre tendremos una Base de Datos en muy buen estado de salud. Podríamos barrer un vez al día, o quizás una vez a la semana, ya dependerá de la cantidad de transacciones que durante ese tiempo ocurrieron. Un método es el siguiente:

  1. Detener el Servidor del Firebird
  2. Reiniciar el Servidor del Firebird (no debería durar ni 5 segundos el ciclo detener/reiniciar)
  3. Abrir la ventanita “Símbolo del sistema”
  4. Ejecutar el comando: GFIX -sweep -user SYSDBA -password masterkey MiBaseDatos

Realizar un ciclo backup/restore puede ser muy complicado en las empresas que trabajan 24/7/365, en cambio el barrido de la basura es más factible de encontrar el momento adecuado para hacerlo.

Sea como sea, mantener la Base de Datos con poca o nada de basura es una tarea muy importante, que está implícita cuando se trabaja con Firebird, y que debe realizarse sí o sí, no hay excusas, al menos si queremos que los tiempos de respuesta que obtienen los usuarios sean aceptables.

Artículos relacionados:

La arquitectura MGA

Entendiendo sweep y garbage collection

El índice del blog Firebird21

El foro del blog Firebird21

 

Cannot attach to password database

4 comentarios

El Firebird guarda los nombres de los usuarios y sus respectivas contraseñas en un archivo llamado SECURITY2.FDB (a partir de la versión 2.0, antes se llamaba SECURITY.FDB)

Si al intentar conectarte a una Base de Datos obtienes el mensaje de error: “cannot attach to password database” eso significa que el Firebird no puede acceder a ese archivo. Las causas posibles son:

  1. No existe el archivo SECURITY2.FDB en la carpeta donde instalaste el Firebird (por ejemplo, en: C:\Archivos de Programa\Firebird\Firebird_2_5\”
  2. Hay instaladas dos o más versiones de Firebird. Y por algún motivo la versión que quieres usar se confundió (este es un caso rarísimo, pero a veces ocurre)
  3. No tienes permiso para leer archivos que se encuentran en esa carpeta. Puedes verificarlo fácilmente tratando de crear en la carpeta donde instalaste el Firebird (por ejemplo, en: C:\Archivos de Programa\Firebird\Firebird_2_5) un archivo de texto llamado PRUEBA.TXT, escribe alguna palabra, graba el archivo y trata de abrirlo con el Bloc de Notas u otro programa. Si no consigues crearlo o leerlo entonces el problema es que te faltan permisos en esa carpeta.

Artículo relacionado:

El índice del blog Firebird21

 

Count of read-write columns does not equal count of values

Deja un comentario

Este mensaje de error puede aparecer cuando se ejecuta el comando INSERT o el comando UPDATE OR INSERT y significa que la cantidad de columnas que se quieren insertar y la cantidad de valores que se guardarán en esas columnas no coinciden.

Ejemplo:

INSERT INTO BANCOS
           (BAN_CODSUC, BAN_IDENTI, BAN_NOMBRE)
     VALUES(0         , 'Citibank');

Como puedes ver, hay 3 columnas en la tabla BANCOS a las cuales se les quiere poner valores, pero hay solamente 2 valores disponibles. Como la cantidad no coincide, ese mensaje de error es mostrado. Evidentemente que la solución es que ambas cantidades sean iguales.

Artículos relacionados

El índice del blog Firebird21

El foro del blog Firebird21

 

¿Cuáles usuarios tienen el rol RDB$ADMIN?

Deja un comentario

Como seguramente sabes, si un usuario tiene el rol RDB$ADMIN en una Base de Datos entonces en esa Base de Datos puede hacer de todo, exactamente igual a que si fuera el usuario SYSDBA o el creador de la Base de Datos.

Por lo tanto, a veces puede ser importante responder a la pregunta: ¿Quiénes tienen el rol RDB$ADMIN en esta Base de Datos?

El siguiente SELECT te lo dirá:

SELECT
   *
FROM
   RDB$USER_PRIVILEGES
WHERE 
   RDB$RELATION_NAME = 'RDB$ADMIN';

Como puedes ver, esa información la extraemos de la tabla RDB$USER_PRIVILEGES pues es en esa tabla donde se guardan todos los privilegios (derechos, permisos) que tiene cada usuario. Obtendremos algo similar a esto:

ADMIN1

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

Entonces, en esta Base de Datos, hay 3 usuarios que pueden conectarse con el rol RDB$ADMIN, ellos son: WOJEDAR, FATIMA y PRUEBA.

Artículos relacionados:

Derechos que poseen los usuarios de la Base de Datos

El índice del blog Firebird21

El foro del blog Firebird21

 

El foro del blog Firebird21

6 comentarios

Gracias a la gran colaboración de mi buen amigo Yván Acosta de Perú desde hoy este blog cuenta con un foro donde los interesados pueden escribir preguntas y respuestas.

El enlace para acceder al foro es:

http://yoforeo.com/firebird21/

o también pueden escribirlo así:

firebird21.yoforeo.com

como recomienda Yván.

Y al ingresar verán una pantalla similar a la siguiente:

FORO1

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

Debes ingresar tu nombre de usuario y tu contraseña como se ve en (1). Si aún no eres usuario entonces debes registrarte para serlo, para ello debes hacer clic en el botón “REGISTRARSE”  como se ve en (2).

Una vez que ya has ingresado al foro puedes elegir donde escribir tu pregunta. Por ahora hay 3 categorías:

    • Conceptos
    • Lenguajes de programación
    • Otros

y 7 sub-foros:

    • Bases de Datos
    • Consultas sobre Firebird
    • SQL
    • Delphi, Java, PHP, Visual Basic, Visual FoxPro, Otros
    • Presentación
    • General
    • Relax

aunque es bastante probable que en el futuro se vayan agregando más, a medida que la cantidad de preguntas y respuestas vayan aumentando y se necesite clasificarlas mejor.

Para hacer una pregunta haz clic en el nombre del sub-foro que consideras más adecuado para esa pregunta. Por ejemplo, si tu pregunta está relacionada con el comando SELECT el sub-foro más adecuado es el llamado “SQL”.

FORO2

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

Una vez que hayas hecho clic en el nombre del sub-foro verás una pantalla similar a la siguiente:

FORO3

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

Puedes escribir una pregunta haciendo clic en el botón “NUEVO MENSAJE” como te lo muestra la flecha (1). Para leer mensajes (y responderlos, si así lo deseas) debes hacer clic sobre el asunto del mensaje, como te lo muestra la flecha (2).

Si haces clic sobre el botón “NUEVO MENSAJE” verás una pantalla similar a la siguiente:

FORO4

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

Como puedes ver, tienes muchas opciones para formatear tu mensaje: puedes escribir texto en negritas, en itálica, subrayado, en colores, cambiar el tipo de letra, el tamaño de las letras, ponerle iconos, etc.

Para ver tu mensaje antes de que sea publicado debes hacer clic sobre el botón “Previsualizar”, que se encuentra abajo y a la derecha. Para que sea publicado y todos puedan verlo debes hacer clic sobre el botón “Publicar”.

Presentación

Hay un sub-foro llamado “Presentación”. Se considera de buena educación presentarse antes de empezar a hacer preguntas en el foro. No es obligatorio presentarse pero si no lo haces quedarás mal con los demás porque no será educado tu actuar.

Conclusión:

La verdad que a este blog le hacía falta un foro para que los lectores puedieran escribir sus preguntas. Cuando tienen dudas a veces las escriben en cualquier artículo e me escriben a mi e-mail particular pero ninguna de esas formas es la adecuada. Esas preguntas muchas veces fueron el motivo por el cual escribí algunos artículos del blog pero otras veces la respuesta solamente la conoció quien envió la pregunta. Desde ahora estaremos mucho mejor organizados, todas las preguntas y todas las respuestas serán visibles para todos y eso nos beneficiará a todos.

Este foro fue creado para que todos quienes tengan dudas sobre Firebird, SQL, o bases de datos, tengan un lugar donde poder escribir sus preguntas. Desde luego que solamente valdrá la pena haberse tomado el trabajo de crearlo si se lo utiliza, si nadie lo utiliza entonces habremos desperdiciado nuestro tiempo. Así que, a usarlo muchachos, que es de todos ustedes.

Artículo relacionado:

El índice del blog Firebird21

Enlace:

firebird21.yoforeo.com

Derechos que poseen los usuarios de la Base de Datos

Deja un comentario

En este artículo ya habíamos visto lo que debemos hacer para conocer los nombres de todos los usuarios de nuestra Base de Datos:

https://firebird21.wordpress.com/2013/10/15/usuarios-de-nuestra-base-de-datos/

Pero a veces nos puede interesar conocer si un usuario tiene derechos (permisos, privilegios) sobre alguna tabla, vista o stored procedure, por ejemplo:

  • ¿SUSANA puede hacerle un SELECT a la vista V_ABM_VENDEDORES?
  • ¿SUSANA puede insertarle filas a la tabla VENTAS?
  • ¿GRACIELA puede ejecutar el stored procedure llamado GRABAR_VENDEDOR?

Toda esa información (y mucha más) la encontraremos en la tabla RDB$USER_PRIVILEGES, como vemos en la Captura 1. Queremos conocer cuales son los derechos del usuario WOJEDAR, para eso escribimos:

SELECT
   *
FROM
   RDB$USER_PRIVILEGES
WHERE
   RDB$USER = 'WOJEDAR'

Y estas son las primeras filas que obtenemos:

DERECHOS1

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

En la columna RDB$PRIVILEGE hay una letra que nos dice que derechos (permisos, privilegios) tiene el usuario:

  • I = INSERT
  • U = UPDATE
  • D = DELETE
  • S = SELECT
  • R = puede relacionar tablas mediante una FOREIGN KEY
  • X = puede ejecutar el stored procedure

El nombre de la tabla, la vista, o el stored procedure se guarda en la columna RDB$RELATION_NAME.

Entonces, para responder a la primera pregunta podríamos escribir algo como:

SELECT
   *
FROM
   RDB$USER_PRIVILEGES
WHERE
   RDB$USER_NAME = 'SUSANA' AND
   RDB$RELATION_NAME = 'VENDEDORES'

 Y si vemos una fila que tiene una letra “S” en la columna RDB$PRIVILEGE, entonces SUSANA sí puede hacerle un SELECT a la tabla VENDEDORES.

Conclusión:

Siempre es importante saber que derechos tiene cada usuario, si no queremos que el usuario MIRTHA tenga un derecho debemos verificar que ya no lo esté teniendo. Los derechos pueden ser otorgados por el usuario SYSDBA, por el creador de la Base de Datos o por cualquier usuario que tenga el rol RDB$ADMIN WITH GRANT OPTION. Si hay un problema de comunicación entre ellos entonces uno podría estar otorgándole un derecho a MIRTHA que MIRTHA no debería tener.

Para estar seguros de que MIRTHA tiene (o no tiene) un derecho lo que debemos hacer es consultar la tabla RDB$USER_PRIVILEGES, ya que es la única forma en que podremos estar 100% seguros de que tiene o no tiene ese derecho.

Artículos relacionados:

Usuarios de nuestra Base de Datos

El índice del blog Firebird21

Algunos ejemplos de uso de las columnas computadas

4 comentarios

Poder tener columnas computadas es una característica muy buena que tiene el Firebird, ya que nos permite tener una columna “virtual”, una columna a la cual nunca se le insertan datos sino que su contenido es calculado (o computado) según el contenido de otra u otras columnas previamente definidas.

Como esta característica no existe en otros motores SQL entonces puede ser de interés mostrar algunos ejemplos de uso.

Ejemplo 1. Mostrando apellidos y nombres

Si has leído algo sobre normalización de tablas entonces recordarás que en una sola columna no deberían encontrarse dos o más datos que significan cosas distintas. Es decir, guardar en una sola columna los apellidos y también los nombres está mal, es incorrecto, deberían guardarse en columnas distintas. Ok, se guardan en columnas distintas, pero al mostrarlos queremos que aparezcan siempre con el mismo formato: los apellidos, una coma, y los nombres. Usando columnas computadas es muy fácil:

CREATE TABLE VENDEDORES (
   VEN_IDENTI D_IDENTIFICADOR NOT NULL,
   VEN_NOMBRE D_NOMBRE20,
   VEN_APELLD D_NOMBRE20,
   VEN_APENOM COMPUTED BY (TRIM(VEN_APELLD) || ', ' || VEN_NOMBRE));

En este caso nuestra tabla de VENDEDORES tiene una columna para guardar los nombres, otra columna para guardar los apellidos, y una columna computada para mostrarlos a ambos.

COMPUTADAS1

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

Los usuarios solamente pueden guardar datos en las columnas VEN_NOMBRE y VEN_APELLD, en la columna VEN_APENOM no pueden hacerlo. Su contenido es calculado (computado) automáticamente por el Firebird.

Por supuesto que en nuestros SELECTs podemos usar cualesquiera de esas columnas.

Ejemplo 2. Mostrando el total vendido de cada producto

CREATE TABLE MOVIMDET (
   MOV_IDENTI D_IDENTIFICADOR NOT NULL,
   MOV_IDECAB D_IDENTIFICADOR,
   MOV_IDEPRD D_IDENTIFICADOR,
   MOV_CANTID D_CANTIDAD,
   MOV_PRECIO D_PRECIO,
   MOV_TOTALX COMPUTED BY (MOV_CANTID * MOV_PRECIO));

En este caso guardamos en la tabla MOVIMDET el detalle de las ventas realizadas. Tenemos una columna para guardar la cantidad vendida, otra columna para guardar el precio unitario y una columna computada para mostrar el importe vendido de cada producto.

COMPUTADAS2

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

En la columna MOV_TOTALX tenemos el total vendido de cada producto, ese valor lo halla automáticamente el Firebird, nosotros no necesitamos calcularlo cada vez que lo necesitemos porque ya el Firebird se encargó de calcularlo para nosotros.

Ejemplo 3. Mostrando la bonificación familiar

En Paraguay (donde reside el autor de este blog) a los empleados se les paga un adicional del 5% por cada hijo menor de 18 años que tienen. Entonces nuestra tabla de EMPLEADOS podría ser similar a esta:

CREATE TABLE EMPLEADOS (
   EMP_CODSUC D_CODIGOSUCURSAL NOT NULL,
   EMP_IDENTI D_IDENTIFICADOR NOT NULL,
   EMP_NOMBRE D_NOMBRE20,
   EMP_APELLD D_NOMBRE20,
   EMP_SALBAS D_PRECIO2,
   EMP_APENOM COMPUTED BY (TRIM(EMP_APELLD) || ', ' || EMP_NOMBRE),
   EMP_CANHIJ COMPUTED BY ((
      SELECT
         COUNT(*)
      FROM
         EMPLEADOSFAM
      WHERE
         EMF_CODSUC = EMP_CODSUC AND
         EMF_IDECAB = EMP_IDENTI AND
         EXTRACT(YEAR FROM CURRENT_DATE) -
         EXTRACT(YEAR FROM EMF_FECNAC) < 18
   )),
   EMP_BONFAM COMPUTED BY (EMP_SALBAS * EMP_CANHIJ * 5 / 100));

Como se puede ver aquí, en una columna computada también se puede usar un SELECT, pero en ese caso hay que escribir dos paréntesis, no solamente uno. Es lo que se hizo en la columna computada EMP_CANHIJ, donde queremos tener la cantidad de hijos menores de 18 años que tiene cada empleado. Los datos de los hijos (nombres, fechas de nacimiento, etc.) se guardan en otra tabla, cuyo nombre es EMPLEADOSFAM (familiares de los empleados).

COMPUTADAS3

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

COMPUTADAS4

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

En nuestra tabla de EMPLEADOS tenemos a dos personas, y como podemos ver estamos usando varias columnas computadas:

  • EMP_APENOM para mostrar los apellidos y nombres del empleado
  • EMP_CANHIJ para mostrar la cantidad de hijos menores de 18 años
  • EMP_BONFAM para mostrar la bonificación familiar que le corresponde al empleado

Relacionamos a ambas tablas mediante las columnas EMP_IDENTI (identificador del empleado) y EMF_IDECAB (identificador de la cabecera).

ADVERTENCIA:

Como hemos visto en el Ejemplo 3. se puede escribir un SELECT dentro de una columna COMPUTED BY pero eso no es recomendable hacerlo en tablas que tienen muchas filas porque por cada empleado se realizará el SELECT correspondiente y eso puede demorar mucho tiempo. En general para estos casos es preferible crear una vista. Usaríamos un SELECT dentro de una columna COMPUTED BY solamente cuando la tabla del SELECT (no la tabla principal, sino la tabla del SELECT) tiene pocas filas y usa un índice.

Artículos relacionados:

Columnas computadas

Usando un SELECT en una columna computada

Un truco para encontrar valores que pueden estar en varias columnas

Utilizando columnas computadas

El índice del blog Firebird21

El foro del blog Firebird21

Utilizando columnas computadas

5 comentarios

En este artículo ya habíamos visto lo que son las columnas computadas y para que sirven.

https://firebird21.wordpress.com/2013/06/23/columnas-computadas/

Ahora la pregunta es: ¿vale la pena usarlas?

La respuesta es un rotundo sí y las razones son las siguientes:

  1. Las columnas computadas (casi) no ocupan espacio en la Base de Datos
  2. En tus aplicaciones escribes menos
  3. En tus aplicaciones siempre obtendrás el mismo valor
  4. Si necesitas cambiar la fórmula, lo haces en un solo lugar

1. Las columnas computadas (casi) no ocupan espacio en la Base de Datos

¿Por qué? porque solamente se guarda la definición de la columna computada, no sus valores. Por ejemplo, si tu columna computada realiza alguna operación matemática entonces podrá ser de tipo BIGINT y ocupará 8 bytes. Nada más. Si la tabla tiene 1.000.000 de filas no se usarán 8.000.000 de bytes sino solamente 8 bytes, los de la definición.

Si quieres tener una columna para guardar en ella el total de la venta de un producto (cantidad * precio) y la defines como una columna normal entonces estarás haciendo dos cosas mal: primero, tu tabla no estará normalizada porque estarás guardando un valor que puede ser calculado y segundo, estarás desperdiciando espacio en el disco duro. En cambio, si la defines como columna computada la tabla continuará normalizada y además no usarás espacio del disco duro.

 2. En tus aplicaciones escribes menos

Si a tu columna computada la llamas, por ejemplo, TOTAL_VENTAS, entonces en tus stored procedures, en tus triggers, y en tu lenguaje de programación solamente necesitarás escribir TOTAL_VENTAS, no tendrás que estar multiplicando CANTIDAD * PRECIO en cada uno de esos lugares, así que ahorrarás escritura. Cuanto más larga sea la fórmula mayor cantidad de caracteres serán los que te ahorrarás de escribir.

3. En tus aplicaciones siempre obtendrás el mismo valor

Como siempre te estarás refiriendo a una sola columna (por ejemplo, llamada TOTAL_VENTAS) entonces en todos tus stored procedures, tus triggers, y en tu lenguaje de programación siempre obtendrás el mismo valor. Si no usas una columna computada podrías equivocarte y en lugar de escribir CANTIDAD * PRECIO escribir CANTIDAD + PRECIO y por supuesto el resultado estará equivocado. Es cierto que no es probable que te equivoques con una fórmula tan sencilla pero te podría ocurrir si estás muy apurado. Y aún más si la fórmula es complicada. Pero si usas columnas computadas jamás tendrás ese problema porque hay una sola fórmula que se encuentra en un solo lugar, así que es 100% seguro de que siempre obtendrás el mismo valor. Si la fórmula es correcta en todos los lugares obtendrás el valor correcto, y si la fórmula es incorrecta en todos los lugares obtendrás un valor incorrecto, pero siempre será el mismo y eso te ayudará si necesitas cambiar la fórmula.

4. Si necesitas cambiar la fórmula, lo haces en un solo lugar

Supongamos que el resultado de CANTIDAD * VENTAS lo necesitas mostrar en 40 lugares distintos. Y después te dicen que hay que multiplicar a ese resultado por 1.1, para aumentarlo en un 10 %. Si no usas columnas computadas entonces tendrás que hacer 40 cambios (y quizás ni te acuerdes que son 40 y cambies solamente en 28, a pesar de que deberías haber cambiado en 40).

Usando columnas computadas no tendrás ese problema, ya que el cambio lo haces en un solo lugar (en la columna definida como COMPUTED BY) y automáticamente ya el nuevo valor estará disponible en los 40 lugares distintos.

Conclusión:

Usar columnas computadas es altamente recomendable porque ahorramos tiempo y ganamos en confianza y en seguridad. Escribimos menos y además si alguna vez necesitamos cambiar la fórmula lo hacemos en un solo lugar.

Artículos relacionados:

Columnas computadas

Algunos ejemplos de uso de las columnas computadas

Un truco para encontrar valores que pueden estar en varias columnas

Usando un SELECT en una columna computada

Indexando una columna computada

El índice del blog Firebird21

El foro del blog Firebird21

Relacionando dos tablas: la forma vieja y la forma nueva

2 comentarios

En Firebird, cuando queremos relacionar dos tablas (o conjuntos de resultados) entre sí tenemos dos posibilidades:

  1. Usando la forma vieja
  2. Usando la forma nueva

Caso 1. Usando la forma vieja

Esta sintaxis fue establecida en el año 1989. Las tablas se listan separadas por comas después de la cláusula FROM y la condición que las relaciona se pone en la cláusula WHERE. No hay una sintaxis especial que distinga cuales de las condiciones del WHERE son para filtrar filas y cuales son para relacionar tablas, se supone que mirando la sentencia el desarrollador sabrá cual es cual.

¿Problemas?

  • La cláusula WHERE puede volverse muy larga y muy complicada de leer porque se la usa para relacionar tablas y también para filtrar filas
  • Solamente se pueden relacionar tablas que tengan valores idénticos, si una de las tablas tiene NULL en una columna no se podrá hacer la relación. En otras palabras: solamente se puede hacer un INNER JOIN, no se pueden hacer OUTER JOIN.

Sintaxis:

SELECT
   MiColumna1,
   MiColumna2
FROM
   MiTabla1,
   MiTabla2
WHERE
   MiCondición

Caso 2. Usando la forma nueva

Esta sintaxis fue establecida en el año 1992. La tabla principal se coloca después de la cláusula FROM y la tabla secundaria se coloca después de la cláusula JOIN, la condición que las relaciona se coloca después de ON. Por lo tanto se puede distinguir fácilmente cual es la condición usada para relacionar a la tablas y cual es la condición usada para filtrar filas, no hay confusión posible.

¿Ventajas?

  • Es muy fácil saber cual es la condición usada para relacionar a las dos tablas
  • Es muy fácil saber cual es la condición usada para filtrar filas
  • La cláusula WHERE es más corta y por lo tanto más fácil de leer que cuando se usa la forma vieja
  • Se puede usar tanto INNER JOIN como OUTER JOIN

Sintaxis:

SELECT
   MiColumna1,
   MiColumna2
FROM
   MiTabla1
JOIN
   MiTabla2
      ON MiCondición

Cuidado:

Tú puedes elegir cualquiera de las dos formas para relacionar tablas pero NUNCA debes mezclarlas. En un SELECT o usas la forma vieja o usas la forma nueva, no las mezcles, porque si las mezclas eso solamente te ocasionará problemas y ningún beneficio.

Recomendación:

La forma nueva es mejor, por eso se la inventó, por eso existe. Si ya tienes SELECTs escritos con la forma vieja y funcionan bien entonces déjalos como están, no los toques, pero para escribir todos tus nuevos SELECTs usa la forma nueva porque es la que verás cada vez más en todos los libros y documentos sobre SQL. Y es además la que siempre se usa en este blog.

Artículos relacionados:

Entendiendo a los JOIN

JOIN implícito y JOIN explícito

El índice del blog Firebird21

 

Arithmetic overflow or division by zero has occurred

Deja un comentario

Si ves el mensaje: “Arithmetic overflow or division by zero has occurred. Arithmetic exception, numeric overflow, or string truncation. String right truncation”

¿Qué significa?

Que el Firebird encontró un error grave y por eso detuvo el procesamiento. Ese error grave pudo ser debido a un error matemático (por ejemplo, división por cero), a un sobreflujo (se quiso guardar en una columna numérica un número mayor al máximo permitido), o un error de cadena (se quiso guardar en una columna una cadena de mayor longitud que la definida).

La última frase: “String right truncation” nos da la pista de cual de esos errores fue detectado. En este caso, se quiso guardar una cadena de mayor longitud que la definida.

Esto puede ocurrir en dos ocasiones típicas:

  1. Al querer hacer un INSERT o un UPDATE a una columna
  2. Al querer hacer un SELECT a una vista cuya tabla ha cambiado su estructura

Caso 1. Al querer hacer un INSERT o un UPDATE a una columna

La columna por ejemplo está definida como VARCHAR(30) y queremos guardar en ella más de 30 caracteres

¿Solución? Aumentar el ancho que la columna tiene en la tabla o disminuir la cantidad de caracteres a guardar en la columna

Caso 2. Al querer hacer un SELECT a una vista cuya tabla ha cambiado su estructura

La columna por ejemplo está definida como VARCHAR(30), creamos una vista que usa esa columna, luego modificamos la columna a VARCHAR(40), al hacer SELECT de la vista obtenemos el error. ¿Por qué? porque la vista es un SELECT compilado y se compiló cuando la columna estaba definida como VARCHAR(30), eso es lo que conoce la Base de Datos. Si más tarde cambiamos la longitud de la columna a 40 la vista no está enterada de ese cambio, detecta una inconsistencia y muestra el error.

¿Solución?

Volver a compilar la vista. Al recompilar la vista, ésta ya usará la nueva longitud.

Para que el cambio tenga efecto deberás desconectarte de la Base de Datos y volver a conectarte.

Artículo relacionado:

El índice del blog Firebird21

 

Older Entries