domingo, 27 de enero de 2008

Optimizando Firebird

Estas son las consideraciones que tomo en cuenta para una adecuada configuración para el servidor Firebird.


El funcionamiento de un Servidor de base de datos es en realidad una mezcla de tres cosas: una computadora que hace de "servidor", el programa FireBird instalado en el, y un fichero de datos (normalmente con extensión .FDB o .GDB) que está almacenado en un disco duro del servidor. Todos estos aspectos del servidor de la base de datos pueden

ser causa de algunos problemas.

La computadora el Servidor

Para la computador que ara de servidor se tiene que seleccionar una con características hardware apropiadas ya que del adecuado rendimiento de esta PC tendrá mucho que ver el comportamiento del servidor de Base de datos. La recomendación es utilizar ese computador de manera exclusiva como servidor de base de datos. Las consideraciones de seguridad tanto a nivel físico como a nivel de software(Sistema Operativo, Cortafuegos, etc.) deben tenerse en consideración ya que de ello dependerá el buen funcionamiento y la seguridad de la base de datos.

Una computadora con unidades de disco antiguas, sin los controladores adecuados, con poca memoria, con el sistema operativo mal configurado, o que se use para otros procesos, afectará a todos los usuarios del servidor de base de datos, así que la selección de una computadora adecuada es una muy buena decisión para incrementar el rendimiento.

Configurar FireBird

Uno de los puntos mas críticos dentro de la configuración del servidor es la asignación de la memoria que se da al servidor (parámetro DefaultDbCachePages) este parámetro en el servidor Superserver esta configurado a 2048 paginas, es necesario incrementar este parámetro para tener un mejor rendimiento. El efecto que tendrá será grande, sobre todo cuando existen muchos usuarios accediendo a la base de datos o para el procesamiento de Consultas SQL complejas.

Sanear sus datos

Este punto debería ser obligatorio, ya que las bases de datos, al igual que los discos duros, se "fragmentan" con su uso diario, e incluso pueden ser más propensas a corromperse tras unos años de uso, y solo un ciclo de BackUp / Restore nos "sanea" estos datos. Con esto se obtendrá una reducción en el tamaño de la base de datos

Tamaño de cache

Simplificando es cuanta memoria RAM reservamos para cada base de datos que abre FireBird, y cuanta más, mejor, claro. Esta memoria se mide en "paginas", y una pagina puede variar de tamaño, siendo el tamaño por defecto de 4KB. Para la mayoría de base de datos. Por defecto el modo "Superserver" de FireBird -la instalación por defecto- usa DefaultDbCachePages = 2048, es decir, unas 8 MB, así que realmente aquí tenemos mucho que ganar poniendo, por ejemplo, 10 veces más (80 MB) o incluso bastante mas. Conviene jugar con ciertos valores y ver como queda el S.O. (Windows o Linux) de memoria libre. Si decidimos usar un GB para FireBird, usaríamos unas cien veces más que lo que viene por defecto, unas 2 millones de páginas, así que DefaultDbCachePages = 204800 podría ser un valor bueno a probar.

Ficheros temporales

Se usan al ordenar datos, es decir, muy a menudo. Estos fichero no deben estar en el mismo disco donde esta la propia base de datos, ya que en ese caso, el manipular ambos ficheros a la vez penalizará la velocidad bastante. Busque en el fichero de configuración “firebird.conf” la clausula TempDirectories y haga que apunte al disco del sistema operativo, o si lo tiene, a un disco extra que use solo para estos ficheros temporales.

Disco RAM

Si tiene RAM de sobra, digamos que mas de 2 GB en sistemas de 32 bits o más de 4 GB en sistemas de 64 bits, la RAM extra puede usarse para dar más velocidad a los temporales creando un "disco RAM". Estos discos, son programas que se instalan y hacen creer al sistema que la memoria es un disco nuevo, pero muy rápido. Si instalamos uno de estos programas y usamos esa unidad como directorio temporal de FireBird, el cambio puede ser espectacular.

sábado, 26 de enero de 2008

Migración de Datos a Firebird (II)

Desarrollada la aplicación de migración de datos (Tablas Dbfs) a Firebird, se pudo realizar grandes migraciones de cientos de tablas con millones de registros, demostrando de esta manera que el software funciona de manera correcta.

El paso siguiente seria desarrollar una herramienta que pudiese hacer los mismo con diferentes orígenes de datos (Principalmente servidores SQL).
Me propuse desarrollar un software que incluyera la siguiente Funcionalidad:
  • Explorar los objetos de un servidor Firebird
  • Exportar Datos y Objetos entre 2 servidores Firebird
  • Exportar las estructuras de Objetos de un servidor Firebird a un Archivo SQL
  • Incluir la Migración de Archivos DBFs
  • Migrar de Datos y Estructuras de un Servidor SQL
  • Migrar datos de origen ODBC o Acces
Aqui pongo unas capturas de pantalla del software desarrollado:

Esta ventana muestra la opción para la migración de estructura y data entre 2 servidores Firebird.

Esta ventana muestra como se puede extraer la estructura de datos y objetos de un servidor Firebird para visualizar o grabarlo en un archivo.

En esta ventana se muestra la opción que permite exportar datos de un un servidor SQL a un servidor Firebird.


El Software puede ser descargado desde Aqui

Migración de Datos a Firebird (I)

Fue inicios del 2004 que decidí desarrollar una herramienta para realizar la migración de data en formato DBF al servidor Firebird.
Este software lo desarrolle con Borland Delphi, una de las partes fundamentales de este software es el objeto que permite acceder a los datos DBFs realizando una adecuada interpretación de estos para su posterior migración a Firebird para un funcionamiento adecuado este software hace uso de Hilos para gestionar la exportación de datos.
Aqui unas capturas de pantallas del software desarrollado:

Esta ventana muestra los diferentes objetos de un servidor Firebird pudiendo analizar las estructuras de las tablas, su data y metadata.


Esta ventana muestra como se puede explorar un directorio para analizar archivos Dbfs, pudiendo visualizar su estructura así como su data


Esta ventana muestra la selección de los diferentes archivos Dbfs a migrar para realizar la exportación de datos al servidor Firebird.


El software puede ser descargado aquí

Conociendo Firebird

Fue a Finales del 2003 que analizando las diferentes bases de datos de código abierto me encontré con este proyecto, el cual me sorprendió ya que se trataba de una rama de desarrollo libre basado en el código fuente de interbase 6.0. Empece a analizar su funcionalidad probandolo en windows empece a utilizarlo con PowerBuilder para lo cual utilizaba una conexión ODC realice las pruebas y quede satisfecho.
Al trabajar con sistemas que utilizaban campos Blob Firebird no presentaba problema alguno y el controlador ODB tenia un buen desempeño, la administración de la base de datos era mínima, con estas características probadas decidí utilizarlo en los proyectos que desarrollaría de ahora en adelante, plantea al SIMA Chimbote la utilización de esta base de datos lo cual se acepto sin problemas.
Firebird al heredar el código de Interbase tiene un estrecho nexo con las herramientas de desarrollo de Borland principalmente con Delphi para el cual existen una gran cantidad de componentes que nos permiten trabajar con una conexión nativa sacando todo el potencial de esta base de datos.
Al empezar a trabajar con Firebird uno de los grandes problemas con los que me enfrente fue el proceso de migración de base de datos desde otros servidores SQL y de data de archivos DBF; para superar este problemas desarrolle 2 herramientas muy útiles que me permiten hacer este trabajo:
  • dbftofib (Permite migrar datos DBF a Firebird)
  • xdatatofib (Herramienta para migrar data de otros servidores a Firebird)
Estas herramientas las desarrolle utilizando Borland Delphi 7.0

miércoles, 23 de enero de 2008

Java Desarrollando una Ventana Mantenimiento

Terminada, el desarrollo de los objetos base y del generador de ventana de datos paso a mostrar un ejemplo de los pasos a seguir. Para el ejemplo se realizara el mantenimiento de una tabla que utiliza en una de sus columnas un estilo de edición en particular, también se debe comentar que la herencia visual de formularios en NetBeans 6.0 no esta implementada como lo conocemos en PowerBuilder, se puede hacer herencia de componentes (Beans) para ello, si deseamos crear un nuevo objeto visual basado en varios componentes se tendría que utilizar un panel y colocar los objetos que se deseen en el.
La técnica que e utilizado es la combinación de plantillas (esto no es herencia) con objetos visuales y a partir de ellos crear las entradas de datos.
En el siguiente vídeo muestro como se crea una ventana de datos(datawindows) utilizando el diseñador que he creado para este fin, hay que percatarnos que el diseñador nos permite establecer un estilo de edición, estos estilos de edición se obtienen de un Paquete el cual muestra los objetos que pueden servir como objetos de edición.

martes, 22 de enero de 2008

Video de la Aplicación

Aqui les pongo un video de como quedo la presentación del primer avance del sistema.

martes, 15 de enero de 2008

Jaybird Problemas ?

5 de Diciembre 2007

He desarrollado ya varias entradas de datos y la verdad con los objetos de acceso a datos que desarrolle las cosas ya son mas aceptables y puedo desarrollar bastante rápido esto me esta gustando.
Toda estaba bien hasta que me percato de algo extraño cuando procedía a grabar datos en una tabla con llave primaria compuesta se modificaban todos los registros para los cuales coincidía el ultimo campo de la llave compuesta me explico mejor con un ejemplo:

TABLA=DEMO1
sistema codigo campo valor
002 1 UNO 100
002 2 DOS 200
002 3 TRES 5000
002 5 UNO 300
002 10 DOS 100
002 20 UNO 200

PRIMARY KEY = CAMPO+CODIGO+SISTEMA

Si yo actualizo el campo valor de 200 a 10 para los registros con el campo sistema='002' y ademas con el campo codigo='20' esto deberia afectar solo a un registro.

Después de realizar la actualización el resultado debería ser este:

sistema codigo campo valor
002 20 UNO 200

Pero los resultados fueron diferentes obteniendo los siguientes datos:

sistema codigo campo valor
002 1 UNO 10 (*)
002 2 DOS 200
002 3 TRES 5000
002 5 UNO 10 (*)
002 10 DOS 100
002 20 UNO 10 (*)

Esto para mi es un Horror, bueno pensé algo estoy haciendo mal así que a revisar todo el código que he avanzado para detectar el posible error ese día me amanecí para variar (jajaa casi siempre lo ago) . Analizando todo llegue a la conclusión siguiente el controlador Jaybird tiene un problema muy pero muy grande como antes no se percataron de eso realmente es algo terrible.

Decidí escribirle a Roman Rowinsky el creador de Jaybir para que me oriente que cosa estava haciendo mal. Roman Rowinsky me contesto lo siguiente:

Please post this email into our bug tracker at
http://tracker.firebirdsql.org

It looks like a bug in JDBC driver when handling the compound primary keys.

Aqui me esta confirmando que efectivamente existe un problema con el controlador JDBC de Jaybird en la actualización de registro con tablas que tienen Llaves primarias compuestas.
Bueno esto me puso muy preocupado, publique el bug en la dirección que Roman me indico y en esa dirección me percate que existen Bugs desde el 2006 que no se solucionan hasta la fecha o si se solucionaron no se menciona nada de ello.

Al percatarme de ello estaba al borde de a locura y que hago me dije lo primero tranquilizarme y pensar friamente que seria los mas adecuado hacer, entonces se me ocurrieron las siguientes alternativas:
  • Cambiarme de Motor de Base de datos
  • Pedirle Porfavor a Roman que me Ayudase con el problema
  • Yo mismo corregir el controlador
Asi que empece a analizar las diferentes alternativas que tenia, la primera cambiarme de base de datos bien a Postgress o Mysql me decidí por Mysql así que estuve explorando las posibilidades con esta base de datos, como se sabe Mysql apartir de la versión 5.0 comienza a dar soporte a Procedimientos almacenados,disparadores , funciones definidas por el usuario, etc. estuve revisando el lenguaje de programación que utiliza Mysql y toda la información que encontré me llevo a pensar que Mysql todavía no esta muy maduro en estos temas como RBDMS, mi conocimiento con Firebird data desde el 2004 y con el cual he desarrollado muchos sistemas, esto me garantizaría tiempo y funcionalidad para la generación de cualquier tipo de reporte por mas complejo que este fuese, con IBSQL (Lenguaje de Firebird) todo lo podría resolver. Así que me propuse Corregir el Controlador yo mismo si en 24 horas no lo podía corregir el cambio de motor de base de datos era inevitable.

Le pedí a Roman que me diga donde podía conseguir el código fuente de Jaybird 2.1.1 (Es la versión que estoy usando) pq' en la pagina de descarga solo se encuentra los fuentes de Jaybird 2.1 Roman me contesto lo siguiente:

You have to check out the sources from the CVS

cvs -d :pserver:anonymous@firebird.cvs.sourceforge.net:/cvsroot/firebird
co -R Jaybird_2_1_1 client-java

Aca entra el excelente soporte que tiene Netbeans 6.0 para el trabajo con CVS es de lo mejor que yo he visto.
Una ves trabajando con los fuentes de Jaybird detecte el problema en la clase FBRowUpdater realice la corrección de manera exitosa compilando nuevamente Jaybird con la versión parchada dando resultados satisfactorios, sinceramente que al ver que la nueva versión compilada de Jaybird funcionaba correctamente, la tranquilidad regreso a mi. Corregir el controlador no fue tarea fácil lo primero, hay que aceptar el reto y tener la seguridad de que todo se puede solo el factor tiempo era mi enemigo. Con este problema superado y habiendo ganado mucho mas experiencia en Java con 1 mes de estar desarrollando en este lenguaje, en ese momento me sentí muy contento y con la confianza de que ningún problema me detendría para desarrollar este sistema.

Le escribí a Roman un correo con el código corregido:

Te agradesco por el apoyo y los fuentes de Jaybird. te envio la correccion que he realizado.
saludosy y Nuevamente Gracias.

Atte.
Oscar Zelada Pozo

//***********************************************************************************************
private int[] getParameterMask() throws SQLException {

// loop through the "best row identifiers" and set appropriate falgs.
FBDatabaseMetaData metaData = new FBDatabaseMetaData(gdsHelper);

ResultSet bestRowIdentifier = metaData.getBestRowIdentifier(
"", "", tableName, DatabaseMetaData.bestRowSession , true);
try {
int[] result = new int[xsqlvars.length];
boolean hasParams = false;
while(bestRowIdentifier.next()) {
String columnName = bestRowIdentifier.getString (2);
if (columnName == null)
continue;

boolean found = false;
for (int i = 0; i <>) && "DB_KEY".equals(xsqlvars[i].sqlname)) {
result[i] = PARAMETER_DBKEY;
found = true;
break;
} else
if (columnName.equals(xsqlvars[i].sqlname)) {
result[i] = PARAMETER_USED;
found = true;
break;
}
//---------Este Else--No es necesario Pq' los elementos del Array se inicializan en cero-----
//---------Como el for siempre recorre todos los parametros de Xsqlvars siempre setea todos los anteriores a cero-----
//----------y si ya se asigno un valor diferente a cero sera chancado por eso esas lineas estan de mas---------
//---------el error era que siempre queda el ultimo campo de la llave primaria y sera el unico------
//--------Que se tomara en consideracion para el where del Update------------------------------------
//--------------Gracias por Todo Roman Saludos desde Peru Atte. Oscar Zelada--------------------
// else
// result[i] = PARAMETER_UNUSED;
}

// if we did not found a column from the best row identifier
// in our result set, throw an exception, since we cannot
// reliably identify the row.
if (!found)
throw new FBResultSetNotUpdatableException(
"Underlying result set does not contain all columns " +
"that form 'best row identifier'.");
else
hasParams = true;
}

if (!hasParams)
throw new FBResultSetNotUpdatableException(
"No columns that can be used in WHERE clause could be " +
"found.");

return result;
} finally {
bestRowIdentifier.close();
}
}


Aqui pongo los binarios de Jaybird 2.1.1 que corrige el problema de llave primaria compuesta por si alguien los necesita.

Presentación del Sistema (Postergado)

30 Noviembre 2007

Llego la fecha de presentación del primer modulo y la verdad que como hemos visto recién estoy empezando con el desarrollo del mismo, así que no me quedo otra cosa que conversar con el gerente y pedirle me amplia la fecha de presentación del avance. Al conversar con el le conté a groso modo los problemas que se me habían presentado sin ahondar en los temas técnicos ni demás, bueno el me dijo que has avanzado, sinceramente sentí vergüenza es la primera vez que me encuentro en una situación así, bueno me comprendió y me dio el plazo que le solicite de 10 días para acabar con la primera parte del sistema.
había trabajado muy duro durante este mes de noviembre, desde hace mucho tiempo que no se me presento un reto de esa magnitud, me confié demasiado pensé en aprender Java solo en 15 días y realizar todo la implementación en otros 15 días mas, pero no fue así, también estuvo el reto de desarrollar todo el marco de trabajo que tenia en PowerBuilder era muy corto el tiempo de 15 días por mas experiencia que aya tenido.
De la forma como lo he desarrollado creo que valió la pena estoy satisfecho ya que estoy empezando ha ver los frutos de mi trabajo así que me tomare un par de días para despejarme.

Empezando el desarrollo del Sistema

28 de Noviembre 2007

Todo sistema desde mi punto de vista debe tener un conjunto de objetos reutilizables así como también funciones para las operaciones repetitivas que se dan, así como un interfaz establecida y que todas las ventanas deben seguir.
Empece a desarrollar la interfaz para todo el sistema así como las diferentes funciones que darán soporte ha esta, no olvidemos la seguridad y los accesos a los usuarios, las concepciones de esto yo las tengo bien claro ya que sera las misma de todos los sistemas que he desarrollado.

Existe un sistema principal, apartir del cual se pueden crear perfiles de sistemas que pueden ser asignados a los usuarios, cada perfil de sistema tiene sus permisos establecidos CLAEP C=creación, L=Lectura, A=Actualización, E=Eliminación y P=impresión, espero escribir otra entrada explicando los detalles de la concepción de seguridad que manejo, regresando al desarrollo del sistema, cree un objeto aplicación con diferentes propiedades que serán utilizadas en el sistema, ademas de la sincronización del menú principal y el árbol de la aplicación.
He utilizado funciones hash(SHA) para la encriptación de las claves de los usuarios, aqui les muestro el código de la función:


Aca una captura de pantalla de la ventana principal, tuve que quitar la imagen real del sistema asi como borrar el nombre del sistema y de la empresa de la barra de titulo por razones obvias.


Internamente existen muchas funciones que realizan diferentes procesos para que toda la aplicación funcione de manera adecuada podríamos mencionar algunas

  • Sincronización de elementos del menú en una base de datos.
  • Generación del árbol apartir de la tabla de elementos de menú
  • Ejecución de eventos del menú atraves de los items del árbol
  • Funciones de seguimiento y registro de sucesos del sistema
Sin darme cuenta en la creación de los objetos de acceso a datos y los demás objetos que forman parte de mi marco de trabajo estoy programando varios miles de lineas en Java ya estoy en condiciones de desarrollar los ingresos mas pesados y empezar a introducirme al mundo de los reportes con Jasper Report e Ireport.

lunes, 14 de enero de 2008

Java Datawindow Manipulación Datos en Grid (IV)

25 Noviembre 2007
Java es muy amplio, las posibilidades son muchas en este maravilloso mundo en el cual recién me estoy introduciendo, realmente me esta costando trabajo desarrollar estos componentes y superar los diferentes problemas que se me van presentando. pensé solicitar ayuda en el medio a algún desarrallador con experiencia en Java y me doy con la ingrata sorpresa que la mayoría de desarrolladores solo han trabajado con consultas simples en Web y el tema de Swing no lo conocen solo han desarrollado pequeñas aplicaciones y nada mas, bueno no me queda otra que seguir avanzando solo, se que podre cometer muchos errores pero tengo la idea de que es lo que quiero y eso es una fortaleza para mi.

Continuando con el desarrollo del objeto datawindow, el problema siguiente que se me presento fue como manejar argumentos de recuperación (Parámetros que se pasaran a una consulta y serán interpretados por esta en tiempo de ejecución) por ejemplo si yo desearía recuperar los datos de un cliente en particular la sentencia SQL se vería mas o menos así:

SELECT * FROM CLIENTES WHERE CODIGO='100000'

Pero que sucede si en tiempo de ejecución yo desearía seleccionar cualquier otro código diferente a '100000', la respuesta esta en los argumentos de recuperación que me permitirían a mi recuperar datos en función a un conjunto de parámetros, también debemos tener en cuenta que no siempre sera un parámetro sino que el numero de parámetros seria variable. Como podria implementear esto en Java ? la respuesta lo encontré en los argumentos variables Java incorpora esta funcionalidad apartir de la maquina virtual 1.5 y el único requerimiento que necesita es que los parámetros variables sean los últimos en ser declarados en el método por ejemplo:

public ejemplo(int opc, String... datos)

En este ejemplo nos percatamos que se esta declarando al final de este método el parámetro datos que seria un parámetro variable, los parámetros variables pueden ser de cualquier tipo, aquí unos ejemplos de como se podría llamar a este método:

ejemplo(1,"Hola1")
ejemplo(1,"Hola1","Hola2)
ejemplo(1,"Hola1","Hola2","Hola3","Hola4")

Todas esta maneras de llamar al método son validas el método tendrá la responsabilidad de analizar el numero de parámetros y procesarlos, para determinar el numero de parámetros solo tenemos que preguntar por su longitud en el ejemplo seria de esta manera:

l=datos.length;

El diseñador de consultas que desarrolle también contempla la creación de argumentos de recuperación lo cual me da flexibilidad para el trabajo con datos.

domingo, 13 de enero de 2008

Java Datawindow Manipulación Datos en Grid (III)

22 de Noviembre 2007
Estoy con el tiempo muy recortado y creo que no terminare el primer modulo ya que en realidad no he tocado nada del sistema que tenia que desarrollar y fundamentalmente me he dedicado a crear las clases de objetos que serán el soporte para el desarrollo del sistema en si.
Mis conocimientos en Java se han ampliado y veo las cosas con mas claridad, pero aun no estoy contento con los resultado obtenidos sobre todo con respecto al factor tiempo.
Ya tengo una versión del objeto datawindow para realizar las pruebas veamoslo en acción.


Aquí podemos ver en el código que el objeto datawindow me esta ayudando bastante pero, no considero adecuado que un sistema tenga muchas sentencias SQL embebidas esto a la largo podría restarle versatilidad al sistema e incrementar el esfuerzo del mantenimiento, ademas de tener muchas lineas de código para inicializar los arrays de visualización , edición, etc. es algo muy operativo y tedioso, sinceramente no me gusta ver mi código de esa manera me pregunto si debería existir alguna manera de tener todos estos parámetros aparte, tener una especie de diseñador de datawindows y simplemente en mi código especificar el nombre de la consulta y de manera automática inicializar todos los arrasy seria muy bueno, esto seria lo ideal.
Esta idea no es mala pero se retrasaría mi proyecto mas días, pero pensando que el sistema que desarrollare es grande creo que valdría la pena desarrollar algo así.

Asi que empece a desarrollar el que para mi seria el generador de mis consultas, los datos de inicialización , colores texto, color de fondo, visible , editable todos estos valores deverias estar almacenados en algún sitio, así que para mi habían 2 alternativas almacenarlos en formato XML o almacenarlos en la base de datos, decidí almacenarlos en la base de datos no me pareció la idea de tener muchos archivos XML por alli sueltos, así que cree las estructuras de tablas necesarias para almacenar los valores de los datawindows en una base de datos.
Decidi hacer la interfaz lo mas sencilla posible por cuestiones de tiempo pero debía ser funcional para permitirme seleccionar los valores de manera practica.
Aqui unas capturas de pantallas del pequeño utilitario para crear los objetos datawindows.







Al desarrollar este programa, empece a probar los objetos que había desarrollado, detectando problemas y posibles errores de programación en estos objetos. Ya estaba conociendo Java, este programa no es muy complejo de desarrollar lo mas importante en todo sistema es la idea la concepción de como se deben realizar las cosas, al finalizar este aplicativo aprendí muchas cosas sobre el manejo de Swing esto me serviría mas adelante para el desarrollo en si del sistema.
Este pequeño aplicativo me permite definir la sentencia SQL apartir de la cual se creara el datawindow. El aplicativo tiene tres pestañas:
  • Primer Pestaña de Ingreso de sentencia SQL y prueba de la consulta.
  • Segunda Pestaña grabar datos de la cabecera y detalle así como modificar los atributos de cada columna del datawindow, en esta pestaña también se puede recuperar datawindows creados para realizar algún ajuste de sus atributos.
  • Tercera pestaña nos permite visualizar el datawindows en modo de ejecución, aqui se nos permite seleccionar cualquier datawindows existente y visualizarlo en modo de ejecución.
Uno de los problemas que se me presentaron es como poder seleccionar diferentes estilos de edición por cada celda del JTable , lo que se me ocurrió fue crear objetos en un Paquete el cual podría ser recorrido en tiempo de ejecución y determinar los objetos existentes en este y mostrarle a los usuarios los diferentes estilos de edición que podrían seleccionar. una vez realizado esto en tiempo de ejecución podría crear una clase dinamicamente así como de ejecutar ciertos métodos de la misma manera, esto lo pude realizar gracias a la reflexión que Java posee.
Aqui una captura de pantalla con los diferentes estilos de edición:


Aqui el código que me permite mostrar los objetos existentes en un paquete:

Aca he realizado algunos filtros en función de los diferentes tipos de objeto, al final retorno el arraylist classes el cual contendrá los nombres de los diferentes objetos que se podrán utilizar como estilos de edición.
El código que permite agregar y crear de manera dinámica un objeto como estilo de edición para una celda del JTable se muestra a continuación:

Utilizando la función forName de la clase class podemos crear una clase apartir de su nombre, con la clase ya creada podemos instanciar un objeto de esta clase haciendo uso de la función newInstance, esta función nos retorna el objeto instanciado del tipo de clase creado anteriormente, la función getMethod me permitirá crear u método apartir de su nombre y los parámetros que se les proporcionen. Solamente nos queda llamar al método con la función invoke de la clase Method. De esta manera haciendo uso de la reflexión se ha podido crear dinamicamente el estilo de edición para la celda del JTable.

Editcell1=new DefaultCellEditor((JComboBox)obj);

Cualquier duda sobre la implementación y sus detalles puedes preguntármelo y gustoso tratare de absolver tus dudas.



Java Datawindow Manipulación Datos en Grid (II)

20 Noviembre 2007

Recordemos que la fecha de presentación del primer modulo del proyecto es el 30 de Noviembre del 2007 y la verdad que el tiempo me quedara corto, desconocía la magnitud del trabajo que me tomaría realizar las implemetaciones de estos Objetos, hasta donde estoy conociendo Java es un lenguaje muy potente y me obliga a pensar todo en objetos pero lo bueno es que todo se puede hacer esto me motiva y se que después de acabar con los objetos que me he propuesto mi desarrollo sera muy rápido.

Ya descrita la implementación de la clase encargada del modelo de datos ahora mostrare la implementación del objeto que extenderá el JTable. Antes de esto describire que funcionalidades debería tener el Objeto datawindow:
  • Deberá permitirme realizar la validación de campos
  • Me permitira personalizar el mensajes de error de validación
  • Los objetos encargados de la edición en cada celda estaran en función del tipo de datos
  • Los objetos de edicición que se utilizaran seran los implementados con anterioridad
  • Se podra especificar que columnas seran visibles
  • Se podrá especificar que columnas serán editables
  • Se podrán especificar los colores de texto y fondo de cada celda
  • Se podrá especificar los títulos de cada columna
  • Se podrá especificar el ancho de cada columna
Decidí implementar estas propiedades como array según los diferentes tipos de datos, aqui muestro la declaración de la clase:




Posiblemente podría aver declarado las propiedades utilizando otros tipos de datos mucho mas eficientes, pero en fin estoy contra el tiempo y espero poder afinar esto de los tipos de datos mas adelante.
Este objeto deberá inicializar los arrays así como inicializar la propiedad del modelo de datos PModelo_data, etc.
Dentro de las propiedades mas importantes de este objeto podemos ver el modelo de datos (PModelo_data) la conexión a la base de datos (PSqlca) el modelo de Columnas (PModelo_columnas del tipo TableColumnModel) y los eventos de las columnas del tipo TableColumnModelListener.
Este objeto implemetara los metodos siguientes:
  • Insertrow
  • Deleterow
  • Retrieve
  • Getvalue
  • Setvalue
  • Close
  • Update
  • Getcolumnname
  • Rowcount
  • Commit
  • Updaterow
Básicamente estos métodos llaman a los métodos con el mismo nombre de la clase datastore y teniendo en cuenta la actualización del JTable atraves de los métodos:
  • fireTableRowsInserted
  • fireTableRowsDeleted
  • fireTableRowsUpdated
También se han creado métodos Setvalue1 y Getvalue1 los cuales actúan sobre la fila actual y solamente se debe especificar la columna y el valor según sea el caso, estos métodos así como los anteriores están sobrecargados para aceptar su llamada ya sea po0r el numero de la columna o por el nombre de esta.

El JTable deja el manejo de os datos a su modelo y tiene una presentación de los datos en función a la clase de estos, esta clase se devuelve en el método getColumnClass del modelo de datos, por ejemplo lo datos tipo texto en un JTextfiel y los datos lógicos en un JCheckbox y así de igual manera con los otros datos. Esto es para la edición la cual es la por defecto pero esto queda a la libertad del programador cambiarlos. La presentación de los datos se realiza con una etiqueta (Jlabel) por defecto, una cosa es la edición de los datos y otra la visualización de estos. Para realizar la personalización de la visualización para el JTable se debe utiliza una clase basada en DefaultTableCellRenderer la cual nos permitirá controlar la presentación de los datos.
Aqui la implementación de una clase que tendrá la función de mostrarnos los datos según los colores que se hayan configurado así como de otras condiciones mas:



Cualquier duda sobre la implementación y sus detalles puedes preguntármelo y gustoso tratare de absolver tus dudas.

jueves, 10 de enero de 2008

El año 2000, Mucho Desarrollo y el Inicio en el mundo de las comunicaciones

Software de Ventas, Compras y Almacén

En el 2000 empecé un proyecto en una empresa de computo, el sistema lo desarrolle en aprox. 2 meses en los cuales entro en producción satisfaciendo los requerimientos y objetivos de la empresa. Los usuarios se sentían contentos con la forma del trabajo del sistema por la facilidad y la interfaz amigable con el que contaba el sistema utilizaba Drag and Drop para facilitar la creación de los documentos de ventas. Las herramientas que utilice fueron PowerBuilder y MS Sql Server, este sistema se convertiría con el tiempo en la base de uno de mis sistemas más solicitados en estos últimos 10 años, este sistema tuvo mucho éxito adaptándose para diferentes giros de negocio como:

• Tiendas de Computo
• Ferreterías
• Grifos
• Farmacias
• Madereras

El año 2000 este software se instalo en una empresa de cómputo, un grifo y una ferretería.
Actualmente este sistema que ya cumplió sus 10 años me lo siguen solicitando para los diferentes rubros de negocios en los cuales los procesos de ventas, compras y facturación son los puntos fuertes del negocio.

DELPHI

Delphi 5, estaba en el mercado y yo me había quedado en Turbo pascal 7, el lenguaje pascal me trae muchísimos recuerdos de mi vida universitaria pues con el aprendí a programar y desarrolle muchos aplicativos con este lenguaje, así que me dije veamos cuanto a evolucionado y probemos esta herramienta.
Normalmente lo que suelo hacer para aprender un nuevo lenguaje de programación u un conjunto de clases y entender su filosofía desarrollo mi aplicativo del tiempo universitario el famoso grafico de funciones matemáticas y los proceso de solución de sistemas de ecuaciones y determinantes, cuando termino el desarrollo de esto recién empiezo con el desarrollo del proyecto en sí. Los aplicativos que desarrolle con Delphi son los siguientes:

• Método Simplex (programación Lineal)
• Calculadora Científica, Gráficos de Funciones operaciones matemáticas (sistemas de ecuaciones, derivadas, integrales y determinantes).
• Generación de impresión de códigos de barras
• Software de comunicación serial y transferencia de archivos
• Muchas DLL que serian llamadas principalmente de PowerBuilder
• Control OCX para graficar funciones matemáticas de cualquier tipo.

C/C++

En ese mismo año empecé a desarrollar un proyecto de comunicaciones que implementaba un navegador Web el cual se comunicaba a un proceso servidor para el control de cibercafés.
La base de programación para el desarrollo del Navegador Web fue el ActiveX de Internet Explorer el cual lo trabaje con visual C++ 6.0 y todo el proceso de comunicaciones a nivel de Socket utilizando la MFC.
Normalmente lo que suelo hacer para aprender un nuevo lenguaje de programación u un conjunto de clases y entender su filosofía desarrollo mi aplicativo del tiempo universitario el famoso grafico de funciones matemáticas y los proceso de sistemas de ecuaciones y determinantes cuando termino el desarrollo de esto recién empiezo con el desarrollo del proyecto en sí.
De esta manera me motivo y logro grandes cosas en poco tiempo.
Cuando empiezo a desarrollar el proyecto ya tengo una buena base y el desarrollo se hace mucho más sencillo.
El proyecto se termino y se entrego funcionando Ok, este proyecto lo tengo muy en mente pues gracias a él me introduje en el mundo de las comunicaciones y los Sockets.

miércoles, 9 de enero de 2008

UNS Sistema de Planillas/ Control de personal

Después de renunciar a la Agroindustria San Jacinto, estuve desarrollando todo el año 1999 y 2000 principalmente en la Universidad Nacional de la Santa y el SIMA Chimbote.

El primer sistema que desarrolle en la UNS fue el sistema de planillas el cual tiene una historia.
La UNS por ser una universidad del estado está sujeta a la burocracia y los temas administrativos propio de instituciones de este tipo. Pero también me enfrentaba a otro problema la confianza que tenía la administración de poner este proyecto en las manos de unos de sus egresados, aunque suene contradictorio la parte administrativa no confiaba en el potencial y la capacidad de sus egresados es escuchaba comentarios como los siguientes:

• Como va desarrollar UNS sistema tan complejo como el de planillas donde ni gente de Lima ni Huaraz han tenido éxito.
• No creo que lo desarrolle si mira la clase de docentes que ha tenido
• Esperemos es cuestión de meses para ver como el sistema nunca funcionara.

Yo ya tenia la experiencia del desarrollo en San Jacinto con los 4 sistemas que desarrolle esto me daba la seguridad de desarrollar el proyecto.
Tuve un gran apoyo de un amigo entrañable (Víctor P.) que me daba confianza y apoyo, el tema de este sistema se transformo en un reto personal de demostrar a la gente de los que se era capaz, el desarrollo empezó inicios de Abril de 1999; la primera planilla se probo finales de mayo y entro en funcionamiento para el mes de Junio de ese mismo año.
En ese lapso de tiempo me enfrente a muchos problemas de diferente índole, pero finalmente el proyecto se termino satisfactoriamente.
Como desarrollador de Software uno se siente contento cuando un sistema tiene una vida no menor de 5 años, fue el tiempo que estime que mi sistema funcionaria y para mi sorpresa el sistema funciono hasta inicios del 2007. Según el comentario de los usuarios que trabajaron con el sistema este pudo realizar los procesos y cálculos de manera correcta, he escuchado muchas críticas positivas tal es así que hasta la fecha se comenta que fue el mejor sistema con el cual los usuarios de planillas han trabajado.
Finalizado el sistema de planillas empezamos con el sistema de registro de personal el cual se desarrollo utilizando las siguientes herramientas:

• PowerBuilder
• Ms Sql Server
• Sybase Adaptive Server

El sistema leía a través de un lector de código de barras el código del trabajador registrando los datos de este en el sistema, también se contemplaban la cuantificación de los descuentos por tardanzas e inasistencias que tenían que reflejar en el sistema de planillas. El sistema funcionaba en línea cuando el trabajador se registraba se podía visualizar la información en el dpto. de personal, el sistema utilizaba la tecnología text to speech para pronunciar el nombre del trabajador registrado así como mostrar su fotografía en el sistema.

Anteriormente en la versión de PowerBuilder 6.5 se podía crear servidores de aplicaciones que utilizándolos con objetos proxy se realizaba un desarrollo de N capas. Utilizábamos esta tecnología para los objetos de la lógica del negocio.

En aquel entonces las redes inalámbricas no eran tan usadas y conocidas como hoy debido al alto costo que esto involucraba. Teníamos 2 Locales que comunicar El campus Universitario y Las oficinas administrativas, por ese entonces la UNS no contaba con internet para lo cual solo contábamos con una línea telefónica.
Se desarrollo un aplicativo para establecer una comunicación entre estos 2 locales, se realizaron 2 versiones del programa de comunicaciones realizando las pruebas con un cable modem null, en este punto 2 amigos me estuvieron apoyando para realizar las comunicaciones David P. Miguel B. después de superar algunos problemas el programa de comunicaciones quedo OK, de esta manera se demostró de manera fehaciente la capacidad y calidad de las soluciones informáticas que se estaban brindando.
recuerdo que le realizamos una demostración a las autoridades y en ese entonces el Decano de ingeniería había regresado de México de una maestría y su comentario fue:"no he visto cosas así por allá con el uso tan avanzado de tecnología"
En este proyecto aprendí cosas muy interesantes con respecto a las comunicaciones seriales y en general y se me abría otro mundo muy interesante para el cual en su momento estaría preparado.
Las tecnologías en este proyecto fueron Sistemas de N capas, Codigos de Barra, text To Speech y comunicaciones seriales.

lunes, 7 de enero de 2008

Java Datawindow Manipulación Datos en Grid (I)

16 de Noviembre del 2007
Desarrollado y probado el objeto datastore, el siguiente paso seria crear un objeto basado en el JTable para manipular y presentar datos. Este objeto seria para mi el Java datawindow.

Conforme pasaban los días mis conocimientos en java se iban incrementado pero no eran los suficiente para poder desarrollar con mas rapidez el proyecto, habían momentos en los cuales la desesperación me embargaba.

El JTable es un objeto muy potente y complejo a la vez, la mayoría de objetos Swing manejan el paradigma vista/controlador. Este paradigma básicamente consiste en que debe haber un objeto encargado de manipular y operar los datos y otro objeto es el encargado de presentarlos.

El objeto JTable al utilizar el modelo vista controlador necesita de un objeto derivado de AbstractTableModel para poder realizar la gestión de los datos.
AbstractTableModel es una clase abstracta por lo cual se deberán implementar los siguientes métodos:

  • public Class getColumnClass(int i)
  • public String getColumnName(int c)
  • public int getColumnCount()
  • public Object getValueAt(int r, int c)
  • public int getRowCount()
  • public void setValueAt( Object valor, int fila, int col )
  • public boolean isCellEditable( int fila, int col )
La mayoría de estos métodos segun su nombre nos hacen suponer cual es su función, asi que me centrare en los métodos que pudieran haber confusión:
El método getValueAt nos permite leer el valor de la celda especificada por la fila y columna (Recordar que la fila y columna empiezan por 0) esto objeto nos devolverá un tipo de datos Object el cual deberá ser interpretado de manera adecuada por nuestro programa.
El método setvalueAt nos permite modificar un valor especificando la fila y columna del JTable.
El método isCellEditable es el encargado de especificar cuando una celda se puede editar tomando como parámetros la fila y la columna.

Aqui podemos ver la declaración así como su constructor de la clase que implementara el modelo:


En la declaración de la clase public class Datawindowmodelozp extends AbstractTableModel implements TableModelListener nos percatamos que aparte de extender la clase AbstractTableModel también estamos implementando la interfaz TableModelListener esto sera necesario si deseamos controlar las modificaciones que se puedan realizar en la tabla, esto se hace con el siguiente metodo:

public void tableChanged(TableModelEvent e)

Este método pertenece a la interfaz TableModelListener el cual debe ser implementado en nuestra clase.
Fijándonos en la declaración de las propiedades de nuestra clase observamos la variable PData
que viene hacer un objeto datastore, esta propiedad sera la encargada de realizar la recuperación de los datos. En los métodos de la clase AbstractTableModel que se implemetaran la propiedad PData sera la encargada de realizar la entrega de los datos así como las modificaciones de estos.
Aqui la implementación de estos métodos:




En el código anterior nos percatamos la transformación que se realiza con las filas y columnas ya que para el JTable las filas y columnas empezaran desde 0 y para el datastore (PData) empezaran desde 1, aparte de ello podemos observar que siempre se verifica la propiedad POpen del datastore, esto se hace con el fin de verificar si el datastore se encuentra abierto o no.
La propiedad PCheckbox es una array de booleanos el cual nos indica cuando un campo es logico o no, aqui es necesario aclarar que como para este proyecto trabajo con Firebird el cual no dispone de campos de tipo lógicos los cuales los implemento como char(1) y realizo la conversión necesaria en los métodos anteriores.
Esta clase implementa otros métodos dentro de los cuales mencionare el método Conectardb() y el método Retrieve() por la importancia que tienen para este objeto la implemtación de estos métodos lo podemos visualizar en la siguiente pantalla:


Hasta este punto solo me he dedicado a describir el modelo de datos que sera el encargado de interactivo con el JTable en las entradas siguientes continuaremos con la explicación de los metodos que tuve que implemntar e el JTable.

Cabe hacer una aclaración que este enfoque y la manera de implementar los métodos están en constante cambio ya que el proyecto esta en evolución y mis habilidades con Java se van incrementando. Recordemos Tambien que estoy contra el Tiempo y lógicamente mas adelante iré puliendo estos métodos pero la idea principal seguirá.
Cualquier duda sobre la implementación y sus detalles puedes preguntármelo y gustoso tratare de absolver tus dudas.

Java Datastore el Pilar de acceso a los datos

12 Noviembre 2007

Con las disculpas a todos los programadores de Java, la nomenclatura que utilizare para las objetos provienen de la costumbre de programar en PowerBuilder.
Creando el Objeto Java Datastore, este objeto seria un objeto no visual, a continuación la declaración y el constructor:


Como podemos ver, las propiedades principales son :
  • PSqlca Objeto Conexión
  • rs Objeto Resultset
  • rsm Objeto Resultsetmetadata
  • stm Objeto Statatement
El objeto PSqlca me permitirá tener una sola conexión ya que esta sera un parámetro del constructor del objeto, generalmente en las ventanas podre manejar varios objetos datastore con una única conexión permitiéndome de esta manera cierto nivel de control de las transacciones sobre el conjunto de datos en una ventana.

El Objeto rs es el encargado de realizar todas las operaciones de recuperación y manipulación de datos.

El Objeto rsm me permitirá recuperar la metadata de los campos ayudándome a determinar los tipos de datos, nombres de las columnas, tamaño, etc.

Este Objeto implementara principalmente los siguientes métodos:
  • Insertrow
  • Deleterow
  • Retrieve
  • Getvalue
  • Setvalue
  • Close
  • Update
  • Getcolumnname
  • Rowcount
  • Commit
  • Updaterow
Lógicamente que el total de métodos que implementa este Objeto son mucho mas. Internamente se realizan las validaciones de los diferentes tipos de datos realizando las transformaciones cuando sean pertinentes. De todos los métodos que menciono en la lista de repente vale la pena aclarar sobre el método Updaterow(), este método tiene la función de actualizar el registro actual del resultset pero sin realizar un commit para aceptar la transacción, la función Update() es la encargada de procesar la transacción.

Las conexiones que utilizare en el sistemas tendrán desactivada la propiedad autocommit permitiéndome aceptar o rechazar la transacción según sea el caso.

Los Objetos Resultset tienen una forma particular de realizar las inserciones de un registro, esto se realiza en 2 pasos, primero se tiene que llamar a la función moveToInsertRow() la cual nos lleva a un buffer donde se realizara la inicializacion de los campos y de la llave primaria( Es responsabilidad de este objeto inicializarla) , en este momento se utilizaran las funciones updateXXX (xxx dependiendo del tipo de datos), hasta este momento los datos de inserción solo existen en un buffer, para volcar estos datos en el resultset se llama a la función insertRow(), es aquí donde los datos serán volcados a la base de datos.
Aqui se nos presenta un problema como el Objeto datastore sabrá que campos son la llave primaria ? para solucionar este problema el objeto implementa un método cuya función es almacenar en un array de String(Cadenas) los nombres de las columnas que son llaves primarias. Aquí el código del método:


Aqui vemos el uso de diferentes funciones las cuales no describiré ya que seria demasiado extenso el tema, sugiero a los lectores buscar en la ayuda para mas detalles de cada una de ellas.
Una vez conocido que campos son la llave primaria el objeto podrá inicializar sus valor teniendo en cuenta el tipo de datos, si no se inicializaran los valores antes de llamar a la función insertRow() en el momento de la inserción, el controlador Jdbc nos arrojaría un error de que la llave primaria no debe ser nula, el objeto implementa un método para tal caso.

Otro problema interesante con el cual me encontré es como el controlador Jdbc en mi caso Jaybird determinaría cuando un campo es autoincremental en la base de datos. Esto dependerá mucho del motor de base de datos con el cual se este trabajando, en mi caso Firebird implementa los campos autoincrementales haciendo uso de Generadores y disparadores . Jaybird no me detecta correctamente los campos que son incrementales, en este caso tuve que implementar un método en el objeto para que me determine este dato, aquí el código del método:

Nuevamente cabe recalcar que este método solo funcionara con Firebird ademas de tener en cuenta una nomenclatura especifica para los generadores, el cual estará en función de la tabla y columna como se muestra en el código, posiblemente otros controladores Jdbc ya tengan este método implementado. Como se puede apreciar la solución que planteo se basa en el uso del repositorio de Firebird.
El problema subsiguiente por cuestión lógica es recuperar el valor del campo autoincremental para lo cual implemente otro método que realiza esta función, como el manejo del repositorio de Firebird no esta muy difundido también pongo el código aquí:


Como es de pensar este objeto tiene muchos métodos y describirlos todos me demandaría muchas hojas y perdería el sentido genérico que pretendo dar sobre los problemas presentados en el desarrollo de este proyecto.
Con mucho gusto aclarare cualquier duda al respecto sobre este objeto solo tienes que preguntar.

domingo, 6 de enero de 2008

Java y los problemas

10 Noviembre 2007

Lo que relatare es lo que le sucede a la mayoría de desarrolladores de sistemas para empresas cuando desean incursionar en el mundo de Java, en mi caso la mayoría de sistema que realice para empresas lo he desarrollado en PowerBuilder, que realmente es una herramienta excelente para el trabajo con base de datos y esto lo digo sin el animo de menospreciar a otros lenguajes de programación.
Una de las características mas impresionantes de PowerBuilder es su control DataWindows el cual ayuda en el mantenimiento y reportes de datos, asi que muchos desarrolladores sabrán a lo que me refiero, este control incrementa tremendamente la productividad en el desarrollo de aplicaciones con esta Herramienta.

Entonces cuando empece ha desarrollar este proyecto me pregunte y Java que control similar a un datawindow o datastore (Datawindow no visual) la respuesta fue no existe un componente similar que nos ayude en el la interacción de datos.
Aqui les muestro una captura de pantalla donde se compara las lineas de código para realizar un mantenimiento sencillo de datos en Java y en PowerBuilder

Esto de repente para algunas consultas Web donde se interactua con pocas tablas es permisible pero en sistemas donde se trabaja con varias tablas simultáneamente y las operaciones de mantenimiento son intensas, esto es impensable y recordemos que estaba contra el tiempo ya había pasado la primera semana y lo único que había hecho es seleccionar las herramientas para desarrollar el proyecto ademas de darme cuenta que estaba en un aprieto.

Jaybird me permite el uso de cursores actualizables y desplazables con esto aceleraria un poco el desarrollo, asi que pense si voy a desarrollar un sistema que finalizado tendra mas de 100 ventanas donde se interactuara en muchos casos con mas 7 tablas por ventana, tengo que tener objetos que me ayuden a desarrollar rápidamente el sistema abstrayendo la complejidad del código.
Así que me propuse desarrollar los objetos que me apoyarían en el desarrollo de aplicaciones con base de datos. La lista de los componentes ha desarrollar serian:
  • Componente similar a un datastore(Datawindow no visual)
  • Componente Similar a un datawindow Basado en JTable (Grid)
  • Componente Similar a un datawindow Tabular
  • Componentes para la edición de datos texto
  • Componentes para la edición de datos Numéricos
  • Componentes para la edición de datos tipo Fecha
  • Componente Combobox data (Vinculado a una Consulta)
Logicamente que estos no son los unicos componentes que he creado pero son los mas importantes. Estos componentes se deberían crear a partir de los componentes Swing base, descarte el uso de OpenSwing pq' la verdad no me gusta su apariencia. Hasta el momento de escribir estas lineas (Enero del 2008) desconozco la existencia de componentes que sean libres y permitan las funcionalidades que he necesitado.

Mi primer Proyecto en Java

1 Noviembre 2007

En Noviembre del 2007 empece a introducirme al mundo de Java a tiempo completo, una empresa me solicito que desarrollo un sistema netamente utilizando software libre, este sistema debería presentar una interfaz rica permitiendo a los usuarios una interacción adecuada con el sistema, a lo cual yo propuse utilizar Java como Lenguaje de programación Firebird como gestor de base de datos, para modelador Dbdesigner.
Lo primero que hice fue buscar el IDE mas adecuado para el desarrollo de este sistema, realizando una comparación entre Eclipse Europa y Netbeans 6.0 , me incline por Netbeans por lo siguiente:
  • Matisse Para crear GUIs ya que el proyecto debería ser Desktop.
  • Un Excelente editor con autocompletación en código
  • Historia Local
  • Excelente para realizar depuración
  • soporte integrado para Subversión
Como controlador Jdbc utilizaria Jaybird 2.1 para la conexión a la base de datos.

Yo me había trazado un cronograma de trabajo en el cual el sistema estaba dividido en tres subsistemas los cuales se deberían presentar a fines de cada mes, es decir mi primer avance debería presentarse el 30 de Noviembre del 2007, lo cual no llegue a cumplir y de aqui en las siguientes entradas les relatare los problemas que se me presentaron.

Conociendo Java

A inicios del 2006, decidí realizar unas pruebas con java, siempre había escuchado hablar mucho de este lenguaje, sintaxis prácticamente igual C++ , netamente orientado a Objetos , multiplataforma, ademas de poder desarrollar aplicaciones en Web, con servidores de aplicaciones, etc. en fin muchas grandes cosas.
Decidí instalar Eclipse sobre Linux para realizar mis primeros pininos en este lenguaje, la verdad que me pareció algo interesante. Eclipse es muy pesado, y la velocidad de ejecución lenta comparado con otros entornos de desarrollo.
Realice una pruebas para mostrar unos registros de una base de datos utilizando un JTable, sinceramente demasiado código para obtener un resultado tan simple. Lo que me sorprendió fue su orientación ha objetos en Java hay que pensar en Objetos ya que el lenguaje te obliga a enfocar los problemas de esa manera.

Sistemas Desarrollados

Actualmente me Encuentro desarrollando Un proyecto en Java del cual he publicado algunos artículos, también dicto clases a la Escuela de Ingeniería de Sistemas e Informática en la Universidad Nacional del Santa.

Les muestro un resumen de los sistemas que he desarrollado los últimos años:


Estas son las empresas en las que he laborado

  • InterAmerican Service CO S.A.C. (Jefe de Sistemas Actualmente)
  • Agroindustrias Pomalca (Jefe de Desarrollo de Sistemas)
  • Universidad Nacional del Santa (Docente Universitario Sistemas)
  • Universidad Nacional del Santa (Desarrollador Externo)
  • Universidad Privada San Pedro (Jefe de Sistemas)
  • Universidad Privada San Pedro (Jefe de Registro Tecnico)
  • Universidad Privada San Pedro (Jefe de Desarrollo de Sistemas)
  • Sima Chimbote (Analista de Sistemas)
  • Sima Chimbote (Administrador de Red)
  • Agroindustrias San Jacinto (Jefe de Desarrollo de Sistemas)
  • Desarrollador y consultor Independiente en varias empresas

Conociendo el Mundo de Delphi

Fue en 1999 cuando al nostalgia me embargo y decidí desempolvar mis antiguos aplicativos desarrollados en Turbo Pascal 7.0 para migrarlos a Delphi. Yo había seguido la evolución de Delphi desde la versión 1.0 de manera teórica pero nunca había manejado el entorno ni desarrollado algún aplicativo.
Asi que decidí migrar mi aplicativo matemático de gráficas y cálculos, ademas de un programa de investigación de operaciones que había desarrollado en mi vida universitaria.
La verdad que me impresiono yo en ese tiempo ya había estado trabajando con PowerBuilder y Visual Foxpro, pero Delphi me maravillo ya que podía hacer cualquier cosa con el el limite estaba en la imaginación es mas con delphi podría ampliar las capacidades de PowerBuilder a trabes de controles OCX.
La migración de mi aplicativo fue rápido creo que me tarde una semana en aprender el lenguaje y realizar la migración, pues yo ya conocía pascal y eso me ayudo mucho.
Aqui unas capturas de pantallas del programita:






Que es Firebird ?

Actualmente me encuentro escribiendo un Libro sobre este excelente gestor de Base de datos ya que no existe bibliografia en nuestro idioma sobre este tema.
Aqui una parte del capitulo de Introducción a Firebird.

Firebird es un Servidor de Base de Datos multiplataforma basada en el código de Interbase 6.0 (Borland Internacional) una base de datos madura con mas de 25 años de experiencia. Interbase 6.0 fue liberado a mediados del 2000 bajo licencia IPL derivada de MPL (Mozilla Public Licencia) es mas permisiva que GPL y similar a BSD.

Jim Starkey trabajaba en DEC en su producto “Datatrive network database” cuando tuvo la idea de un sistema que manejara cambios hechos concurrentemente por varios usuarios. La idea simplificaba dramáticamente los problemas existentes del control de concurrencia utilizando trancas (locking), los cuales representaban un serio problema para los nuevos sistemas de base de datos relacionales que se estaban desarrollando en ese momento. Entonces comenzó a trabajar en el sistema en DEC, pero en ese momento DEC comenzaba el desarrollo de una base de datos relacional que resultó en el producto Rdb/VMS. Cuando se enteraron de su proyecto se desató un gran problema, y Starkey eventualmente decidió desistir.

Starkey se enteró que el proveedor de plataformas locales Apollo Computer buscaba una base de datos para sus máquinas Unix, y accedían a solventar su desarrollo. Con su apoyo, Starkey formó Groton Database Systems (Groton, Massachusetts era el lugar donde se encontraban) en 1984 y comenzó a trabajar en lo que eventualmente sería lanzado como Interbase en 1986. Apollo sufrió un inconveniente corporativo y decidió dejar el negocio del software, pero en ese tiempo el producto ya estaba generando dinero.

Entre 1986 y 1991 el producto fue gradualmente vendido a Ashton-Tate, creadores del famosos dBASE, quienes en ese entonces se encontraban comprando varias compañías de base de datos con el fin de ampliar su catálogo. La compañía cayó rápidamente y Borland la compró en 1991, adquiriendo Interbase como parte del trato.

A principios del año 2000, la compañía Borland anunció que el código de Interbase sería liberado en la versión 6.0 y comenzó las negociaciones para que una empresa separada se encargara del nuevo producto. Cuando los responsables de esta nueva empresa y Borland no llegaron a un acuerdo de separación, Interbase permaneció como un producto de Borland y el código fuente de Interbase 6 se liberó bajo una variante de la “Mozilla Public License” a mediados del 2000.

Con la división de Interbase en Borland, la compañía liberó una versión propietaria de Interbase 6 y luego 6.5. Borland liberó varias actualizaciones para la versión libre antes de anunciar que ya no participaría activamente en el desarrollo de este proyecto. De aquí nació una nueva rama de desarrollo libre basada en el código abierto de Interbase 6 que daría vida a Firebird.

El motor de bases de datos Firebird ha sido desarrollado por un equipo independiente de desarrolladores voluntarios a partir del código fuente de Interbase 6.0. El desarrollo del código Firebird 2 arranca inicialmente en el desarrollo de Firebird 1, con el traspaso del código C de Firebird 1 a C++ y la primera gran limpieza en el código. Firebird 1.5 es la primera versión del código Firebird 2. Ello supone haber cubierto una etapa muy importante para los desarrolladores y el propio proyecto Firebird, pero no es un fin en sí mismo. Cubierta la etapa de la liberación de Firebird 1.5, el viaje hacia Firebird 2 prosigue con importantes modificaciones.

La versión 1.5 ha sido construida a partir del código portado del original en C a C++, un proceso iniciado por Mike Nordell en el año 2000. La limpieza total del código y la corrección de errores ha continuado, completada por un nuevo gestor de memoria y mejoras en el lenguaje. No menos importantes han sido los cambios experimentados por el optimizador de consultas SQL durante el proceso de desarrollo de la v. 1.5, con mejoras y correcciones de la mano de Arno Brinkman y otros, cuyo resultado ha sido una mejora en la velocidad de entre un 30 y un 60 por ciento como mínimo.

Firebird 2.0 trae una gran colección de muy esperadas mejoras que aumentan significativamente la performance, seguridad y el soporte de idiomas internacionales, y además brinda algunas deseables nuevas características en el lenguaje SQL. Entre las novedades se incluyen:

  • Nuevo backup incremental.
  • El tamaño de las tablas ya no es limitado a 30 Gb.
  • Soporte para arquitecturas de 64 bits (Intel EM64T y AMD64).
  • Interface tipo plugin para juegos de caracteres internacionales.
  • Soporte de tablas derivadas, como se define en SQL200x, incluyendo anidado multi-nivel y joining de "subqueries".

A la fecha de publicación de este libro la última versión de producción es la 2.0.1 que incluye muchas mejoras sobre su versión predecesora. Firebird tiene una implementación de SQL muy cercana al estándar ISO/IEC 9075. Cuenta con la mayoría de las instrucciones DDL y DML estándar de SQL además tiene un muy Buen Trabajo de Transacciones así como soporte de procedimientos almacenados, Triggers, Vistas, Funciones Definidas por el Usuario, Generadores, etc. Todo esto lo convierte en una de las mejores alternativas en la actualidad a los motores de base de datos comerciales.

Firebird es muy práctico en todo sentido. Sencillo de instalar, fácil de usar, requiere poca administración y es gratuito.

Firebird se ejecuta en la mayoría de sistemas operativos mas difundidos como Windows, Linux, Solaris, MacOS y FreeBsd soportando las arquitecturas de 32 bits y 64 bits. Firebird ha sido probado en entornos financieros y en la actualidad es utilizado por diferentes empresas a nivel mundial. Firebird esta orientado a todo tipo de empresas pequeñas, medianas y grandes; se destaca un buen ejemplo:

Avarda (russian ERP) trabaja con Firebird 2.0 Classic server y con una media de 100 conexiones simultaneas accediendo a una base de datos Firebird de 120Gb con 700 millones de registros! El Servidor es una maquina SMP (2 CPUs - Dell PowerEdge 2950) con 6GB RAM.

En América Latina podemos encontrar un gran desarrollo en Brasil, dado que Brasil Esta apostando por el Software Libre. La iniciativa incluye planes para exportar 2 Billones de Dólares en valor de software por año; reemplazar MS-Windows con Linux en 300,000 computadoras del gobierno federal; canalizar 1 Billon de Dolares en recursos desde telecomunicaciones (Telecommunications Fund - Fust) hasta el sistema basado en software libre llamado Digital Communications System (SCD); e integrar las 200,000 escuelas publicas del país en tecnologías libres.

En Brasil existen una gran cantidad de empresas que utilizan Firebird como base de datos, el tamaño de base de datos varían desde los Megabytes hasta 50 Giga Bytes. Existe Gran cantidad de Información y recursos de Firebird en Internet gran parte Open Source y Otras comerciales gran parte de ellas asociadas a los productos de Borland como son Delphi y C++ Builder, que son la base del desarrollo de muchas utilidades y herramientas de administración, migración, recuperación, etc.


Versiones Actuales

A fecha de publicación de este libro La ultima versión de firebird es la 2.0.1 y es la que se recomienda para producción en entornos empresariales ya sea en la plataforma Windows o Linux. También se encuentra en producción la versión 1.5.4 que es utilizada en la actualidad por muchas empresas.

La recomendación es realizar una migración a la versión 2 por tener un mejor rendimiento asi como muchas mas funciones. Esto se debe hacer con sumo cuidado realizando los backups previos ya que la estructura interna ODS en Firebird 2.0 es diferente que en las versiones anteriores.


CARACTERÍSTICAS DE FIREBIRD

Soporte completo de Procedimientos Almacenados y Triggers

  • Las Transacciones son totalmente ACID compliant
  • Integridad referencial
  • Arquitectura Multi Generacional
  • Muy bajo consumo de recursos
  • Completo lenguaje para Procedimientos Almacenados y Triggers (PSQL)
  • Soporte para Functiones externas (UDFs)
  • Poca o ninguna necesidad de DBAs especializados
  • Prácticamente no necesita configuración - ¡sólo instalar y empezar a usarla!
  • Una gran comunidad y muchas páginas donde consegir buen soporte gratuito
  • Docenas de herramientas de terceros, incluyendo herramientas visuales de administración, replicación, etc.
  • Escritura segura - recuperación rápida sin necesidad de logs de transacciones
  • Muchas formas de acceder a tus bases de datos: nativo/API, driver dbExpress, ODBC, OLEDB, .Net provider, driver JDBC nativo de tipo 4, módulo para Python, PHP, Perl, etc.
  • Soporte nativo para los principales sistemas operativos , incluyendo Windows, Linux, Solaris, MacOS.
  • Backups incrementales
  • Disponible para arquitecturas de 64bits
  • Completa implementación de cursores en PSQL

El servidor Firebird viene en tres versiones: SuperServer, Classic y Embedded. Puedes empezar con SuperServer. Actualmente, Classic es el recomendado para máquinas con SMP y algunas otras situaciones específicas. SuperServer comparte su caché para todas las conexiones y usa un hilo de ejecución para cada conexión. Classic inicia un proceso de servidor independiente para cada conexión que se haga.

La versión embedded es una interesante variación del servidor. Es un servidor Firebird con todas sus características, empaquetado en unos pocos ficheros. Es muy fácil de usar, El servidor no necesita instalación. Ideal para CDROM de catálogos, demos o aplicaciones de escritorio monousuario.

Firebird viene con un completo paquete de utilidades de línea de comando que te permiten crear bases de datos, generar estadísticas, ejecutar comandos y scripts SQL, hacer y recuperar copias de seguridad, etc. Si prefieres usar herramientas visuales, hay una gran cantidad de alternativas donde elegir, incluyendo gratuitas. Se da un listado de estas Herramientas en el Anexo (¿?)

En Windows, puedes ejecutar Firebird como servicio o como aplicación. El instalador puede crear un icono en el panel de control que te permitirá controlar el servidor (iniciarlo, pararlo, etc).

FACILIDAD DE INSTALACIÓN Y MANTENIMIENTO

Firebird es una base de datos que presenta una fácil instalación ya sea en las versiones para Windows o Linux.

En la plataforma Windows Firebird utiliza el típico instalador siguiente y siguiente y listo ya se tiene firebird instalado en el sistema.

En la plataforma Linux la instalación también es muy sencilla solo basta utilizar el comando rpm para proceder con la instalación, finalizado este proceso ya tenemos instalado el servidor firebird listo para activarlo como servicio que se inicie al arrancar el sistema.

Con respecto al mantenimiento se dice que firebird no necesita casi de este, otras bases de datos necesitan de la presencia de un DBA experimentado para su correcto funcionamiento. Con firebird se puede trabajar sin problemas sin tener la presencia de un DBA experimentado debido a la simplicidad de su forma de trabajo lo cual se convierte en una gran ventaja. Esto no quiere decir que firebird se da mantenimiento solo, sino siempre abran algunas tareas que realizar por el DBA.


PROTOCOLOS DE RED SOPORTADOS


Los protocolos soportados por Firebird son los siguientes:

  • TCP/IP
  • Named Pipes
  • TCP/IP Loopback
  • Acceso Local para Windows


TCP/IP.-

Firebird soporta el protocolo TCP/IP para los diferentes tipos de servidores y clientes.

Este protocolo es el recomendado a utilizarse en las diferentes plataformas soportadas, ya que nos permite utilizar todas las capacidades de comunicación entre clientes y servidores.


Named Pipes.-

Firebird Soporta el protocolo Microsoft Wnet Named Pipes para Windows NT/2000/XP servidores y clientes, el nombre del pipe por defecto es interbas.

Las versiones de Windows 95/98/ME no soportan este protocolo.


TCP/IP Loopback.-

El acceso local al servidor puede realizarse de manera local con la interfaz Loopback que tiene la dirección 127.0.0.1. El servidor embebido de Firebird no soporta este tipo de conexión.


Acceso Local para Windows.-

Para clientes instalados en el mismo servidor de Windows Firebird simula una conexión de red con la tarjeta de red utilizando para ello un mecanismo de comunicación entre procesos. Este protocolo de comunicación es el utilizado por el servidor embebido de Firebird.

TIPOS DE SERVIDORES

Firebird Se distribuye en tres tipos de servidores el Clasic Server, el Superserver y el Embedded.

CLASIC SERVER

Crea un proceso y reserva un número de MB por cada usuario que se conecta.

Como Firebird no soporta aun el trabajo con SMP, en servidores con varios microprocesadores es recomendable dejar que el sistema operativo realice el balanceo de carga en los diferentes microprocesadores, esto es posible debido a que el servidor Clasic lanza un proceso por cada conexión. Se debe tener en consideración que a mayor cantidad de conexiones el uso de la memoria RAM se incrementa notablemente, por canda conexión de usuario se utiliza aproximadamente 2MB de Memoria.
Si instalamos esta versión, debemos tener en cuenta al elegir el tamaño del cache que

asignamos a cada conexión en esta versión el cache es de 75 paginas por usuario (300KB).

SUPERSERVER

Se crea un hilo por cada usuario que se conecta al servidor, se reserva un número de MB por cada base de datos a la que se accede en cada momento, por tanto no se necesita más RAM en el servidor conforme se da servicio a más usuarios, pero a cambio de eso, un único proceso (fbserver) es el encargado de dar ese servicio a todos los hilos que atienden a los usuarios, esto hace que en servidores que cuentan con mas de un microprocesador solo se utilice uno.

Resumiendo, esto quiere decir que podemos tener muchos usuarios pero la velocidad de proceso se la dividen entre ellos usando solo un procesador del servidor.
La versión 3 de FireBird, eliminará esta limitación en el número de procesadores.

EMBEBIDO

Un servidor embebido es un cliente con un servidor totalmente funcional enlazado como una librería dinámica (fbembed.dll). Tiene la misma capacidad que un Superserver Común y exporta los puntos de entrada del API estándar de Firebird.

Es muy fácil de usar, El servidor no necesita instalación. Ideal para CDROM de catálogos, demos o aplicaciones de escritorio monousuario.

COMPARACION ENTRE CLASIC SERVER Y SUPERSERVER

CLASSIC SERVER

SUPERSERVER

Completamente maduro en Linux; todavía 'experimental' en cierta forma, en Windows.

Completamente maduro tanto en Windows como en Linux.

Crea un proceso por cada conexión cliente, cada uno con su propio caché. Utiliza menos recursos si la cantidad de conexiones es baja.

Proceso único con un hilo de ejecución (thread) separado para cada conexión. Se comparte el espacio de caché. Más eficiente si crece el número de conexiones simultáneas.

Permite E/S directa, rápida, a archivos de bases de datos para conexiones locales (sólo Linux).

Las conexiones locales deben hacerse con la forma de acceso remoto, conectando a localhost. En Windows se pueden hacer conexiones locales, pero no son tan veloces como las de la versión “Classic” en Linux, y también son menos seguras.

Windows: implementados parcialmente Services Manager (Administrador de Servicios), tareas de soporte como backup/restore, database shutdown (sacar de línea la base de datos) etc. a través de la red. Otras tareas de servicio tienen que ser realizadas localmente usando las herramientas cliente (pequeños ejecutables independientes) que vienen con Firebird. Linux: Administrador de Servicios completo.

Administrador de Servicios completo (en Windows y Linux) que le permite realizar tareas de administración (backup/restore, database shutdown, manejo de usuarios, estadísticas, etc.) programáticamente. Se puede conectar al Administrador de Servicios a través de la red y por lo tanto realizar estas tareas en forma remota.

Soporte para SMP (multi-procesador). Mejor rendimiento en caso de un pequeño número de conexiones simultáneas que no se influencian entre sí.

No hay soporte para SMP. En máquinas multiprocesador con Windows, el rendimiento puede incluso caer dramáticamente cuando el SO cambia el proceso entre las CPUs. Para prevenir esto, fije el parámetro CpuAffinityMask en el archivo de configuración firebird.conf.