Cliente para HSQLDB en Windows

sábado, 26 de enero de 2013

Bases de datos en memoria

Cuando comenzamos a trabajar con las bases de datos en memoria como lo son H2, HSQLDB (antes HypersonicSQL) o Derby, encontramos que son excelentes herramientas para tener acceso rápido a datos persistentes; y que ofrecen grandes ventajas para construcción de software de todo tipo en Java. Ya sea como base de datos temporal de nuestra aplicación empresarial, para ejecución de pruebas o para demostraciones a los clientes, siempre se hace indispensable la administración visual de estas bases de datos, tablas, registros, etc.

Las herramientas gráficas de administración de las RDBMS como los TOAD, SQLyog, MySQL Workbench, SQL Developer, entre otros, ofrecen grandes facilidades para las bases de datos correspondientes. Pero, ¿y para las bases de datos en memoria? 

SQuirreL SQL Client es la herramienta gráfica que utilizo para visualizar mis bases de datos en memoria, ya sea con H2, HSQLDB o Derby, aunque también soporta otros motores de bases de datos tradicionales.

SQuirreL SQL Client es muy sencillo de configurar y utillizar. Pero con la introducción de Windows Vista/7 encontré un problema al intentar instalarlo y posteriormente al intentar correr la herramienta.

Mi ambiente de trabajo:
  • Laptop Mexicana 
  • Procesador de 64bits
  • 8GB de RAM 
  • Windows 7 Professional de 64 bits

Problema al instalar SQuirreL SQL Client en Windows 7

El primer problema surgió al intentar instalar SQuirreL, ya que no permitía crear la carpeta de instalación en Program Files (x86), esto por el permisos de seguridad.
Tratándose de un archivo JAR el instalador del programa, Windows no da la opción de Correr en modo administrador.
Por lo tanto, al intentar crear la carpeta de instalación de SQuirreL muestra el error: "This directory can not be writtenPlease chose another directory"
La instalación se lleva a cabo con el clásico Next>Next.

  










 



Solución 1 al problema de seguridad: Desactivar la seguridad del control de acceso

Para solucionarlo se puede bajar el nivel de seguridad en el control de acceso de Windows. Esto significará reiniciar el equipo antes de poder ejecutar nuevamente la instalación, y nuevamente después de haber instalado para incrementar nuevamente la seguridad. Procedimiento para desactivar UAC. No queremos esto.


Solución 2 al problema de seguridad: Abrir desde navegador

Otra opción para poder ejecutar completamente la instalación de SQuirreL, es 

  1. Abrir un navegador de Internet (IE) en modo administrador (Para este caso no usaremos Google Chrome)
  2. Arrastrar y soltar el instalador de SQuirreL en la ventana del navegador. En mi caso: C:\downz\squirrel-sql-3.3.0-install.jar. O copiar la ruta del archivo del Explorador de Windows y pegarlo en la barra de direcciones del navegador.
  3. En la ventana de diálogo, seleccionen Abrir.


Esto ejecutará el archivo de instalación en modo administrador, con lo que permitirá terminar la instalación del programa.


Problema para ejecutar el programa recién instalado y solución

Al finalizar la instalación de SQuirreL podríamos comenzar a usar la aplicación. Pero surge ahora un nuevo problema. Al hacer doble clic o correr el archivo por lotes que ejecuta el programa, simplemente no lo carga. El problema está en que el archivo por lotes que ejecuta el programa necesita una corrección ya que la ruta de instalación de Java, apuntado por nuestra variable JAVA_HOME contiene espacios. Por ejemplo, C:\Program Files (x86)\Java\jdk1.6.0_17. Para solucionarlo, editaremos el archivo squirrel-sql.bat modificando la línea set IZPACK_JAVA=%JAVA_HOME% agregándole comillas set IZPACK_JAVA="%JAVA_HOME%". Con esta modificación ya será posible ejecutar y comenzar a usar nuestro cliente de gestión de bases de datos en memoria.


Últimas anotaciones

Claro que podríamos habernos evitado todo esto con solo seleccionar una ruta distinta para instalar nuestro programa. Pero nosotros los programadores en ocasiones... 

Disfruten tirando código.

Problema al crear nuevo módulo de un proyecto Maven

miércoles, 12 de septiembre de 2012

Al estar creando un nuevo módulo para un proyecto Maven usando Spring Source Tool Suite 2.9.2.RELEASE surgió el siguiente error:

Could not calculate build plan: Failed to parse plugin descriptor for org.apache.maven.plugins:maven-resources-plugin:2.4.3 (C:\Users\jruiza\.m2\repository\org\apache\maven\plugins\maven-resources-plugin\2.4.3\maven-resources-plugin-2.4.3.jar): error in opening zip file
Failed to parse plugin descriptor for org.apache.maven.plugins:maven-resources-plugin:2.4.3 (C:\Users\jruiza\.m2\repository\org\apache\maven\plugins\maven-resources-plugin\2.4.3\maven-resources-plugin-2.4.3.jar): error in opening zip file
El problema surge porque STS viene configurado por defecto para usar la librería de Maven embebida, sí, la que viene con el IDE, y esta tiene sus propias configuraciones como la ruta del repositorio de librerías. Al ser así, Maven intenta encontrar el repositorio en la ruta por defecto establecida, que es C:\Usuario\.m2\repository\ pero mi repositrio existe en otra ruta, por lo tanto ocurre este error.
Para solucionarlo simplemente modifiqué las configuraciones de la instalación de Maven y el repositorio.

Desde el menú superior: Window>Preferences>Maven>Installations
Aquí agregué una nueva instalación de Maven, la cual estoy usando en lugar del que viene embebido con STS.
Desde el menú superior: Window>Preferences>Maven>User Settings
Aquí seleccioné el archivo de configuración de Maven que requiero usar. De esta forma toma la ubicación del repositorio de Maven que tengo configurado en el archivo.


Una vez hechas estas configuraciones volví a intentar crear el nuevo modulo de Maven y funcionó correctamente.


Depurar codigo desde Eclipse usando el plugin de Jetty para Maven

martes, 10 de enero de 2012

Hace ya un tiempo estuve desarrollando una aplicación usando Maven como sistema de building. Pero llegué al punto de que cuando quería depurar la aplicación desde Eclipse, simplemente por la forma en la que funciona el plugin de Jetty para Maven, no me redirigía al código fuente cuando se detenía en un breakpoint, sino en el .class, claro, eso es un problema cuando necesitas ver las líneas de código. Pues bien, luego de un poco de búsqueda, encontré que en la documentación del plugin de Jetty explican cómo lograr depurar el código fuente.

Simplemente es necesario seguir el tutorial que está disponible en

Con esos dos pasos se puede comenzar a depurar el código usando Eclipse, un poco tedioso pero muy rápido de configurar y funciona muy bien.