Que componentes debo usar?

[sitrico] · #1 27-07-2004

Estoy desarrollando una aplicación contemplando la posibilidad de tener 2 versiones, una con tablas planas (BDE) y la otra cliente servidor.

Para eso he tenido mucho cuidado en realizar todo el acceso a datos usando TQuerys y sentencias SQL pero en varios hilos he leido "No uses el BDE para conectarte a..." lo que me parece lógico para una aplicación Cliente/Servidor.

Ahora bien, creo que los componentes tQuery se conectan con el servidor usando precisamente un alias del BDE y por lo tanto el DBE.

Otro detalle importante es que me gustaría que la aplicación no se conectara con un servidor "unico" de base de datos, sino que más bien pudiera usar varios segun la configuración del usuario (o al menos MSSQL, ORACLE y IB/FB).

¿ Los componentes TQuery dependen siempre del BDE ?

¿ Es posible (o práctico) dejar al usuario seleccionar el motor de base de datos a usar ?

He tratado de simplificar mi pregunta, pero en realidad, me gustaría una sugerencia sobre la forma apropiada (y sencilla) de conectar una aplicación a un motor de base de datos segun la selección del usuario.

ruina · #2 27-07-2004

mmm veamos, en realidad usar el BDE en si, no es malo, de hecho el BDE te "regala" un monton de cosas, como por ejemplo cursores bidirecionales, que sirven para, por ejemplo, mostrar los datos en un grid.

Tenia yo una aplicación Cliente Servidor en D4 estupenda corriendo bajo el BDE.

La alternativa es dbexpress + clientdataset, esto quiere decir (casi automaticamente) actualizaciones en cache que, particularmente, me parecen bastante mas complicadas que la vieja y directa TTable.

Cita:

Ahora bien, creo que los componentes tQuery se conectan con el servidor usando precisamente un alias del BDE y por lo tanto el DBE.

Realmente no necesitas un "alias persistente" para conectarlos, deberias usar un TDatabase y conectar todos tus querys a él.

Cita:

¿ Es posible (o práctico) dejar al usuario seleccionar el motor de base de datos a usar ?

Bueno, es posible hacerlo, pero significa mucho mas trabajo para ti, hay que tener en cuenta que no todo el SQL es igual (de hecho se parecen de puro milagro)

Concretamente con esas 3 bases de datos no tendrias problemas de "conexión", ni con el DBE ni con dbexpress.

[sitrico] · #3 27-07-2004

OK, por lo visto no voy tan mal encaminado como me habia parecido, la duda se me presentó porque es la primera vez que uso exclusivamente sentencias SQL para accesar las tablas

Cita:

(de hecho se parecen de puro milagro)

En cuanto a la compatibilidad de los diferentes SQL's creo que no debo tener mayores problemas porque practicamente todas las instrucciones son de tipo

Código SQL [-]Select (lista de campos) From (dase de datos) 

Insert Into Tabla (Campo1, Campo2, Campo3)
Values (:Campo1, :Campo2, :Campo3)

Update ...
Delete ...
Drop Table ..
Create Table ...

y todos los valores los paso como parametros:

Código Delphi [-]q.ParameterByName('Campo').AsTipo := Valor

Mi duda es que es algunas tablas uso campos de autoincremento (AutoInc) lo que no se si sirva en todos los casos

Cita:

deberias usar un TDatabase y conectar todos tus querys a él

En lugar de un TDatabase, lo que hago es crear una variable global (String) DBAlias y asignarla a cada TQuery antes de abrirlo.

Código Delphi [-]q.DatabaseName := DbAlias;

En cuanto al TDatabase, para usarlo tendría que un módulo de datos o algo parecido para centralizar los TQuerys y Asignar el Database del TQuery en Lugar de DatabaseName (esto en principio suena mejor).

En la aplicación no he usado un módulo único de datos, sino más bien he creado uno o dos TQuerys en el formulario (como componentes o por código según el caso) para realizar las diversas acciones (Select, update, Insert delete, etc).

Y para ser sincero en la prueba que acabo de hacer no pude ni asociar mi alias al TDatabase y menos a los TQuerys pero voy a seguir probando.

(Un poco de ayuda no me vendría mal).

Lo que si es seguro es que tendré que distribuir el BDE junto con la aplicación y agregar (al menos) un formulario especializado para conectar la aplicación con cada motor de base de datos soportado.

Cita:

La alternativa es dbexpress + clientdataset, esto quiere decir (casi automaticamente) actualizaciones en cache que, particularmente, me parecen bastante mas complicadas que la vieja y directa TTable

Creo que en esta oportunidad aceptaré de buena gana los "Regalos" de BDE.

Gracias.

ruina · #4 28-07-2004

vamos por partes:

Conectar tu database a los querys:
Te sugiero que crees (al menos) un Datamodule. (en delphi: file new datamodule), le cambias el nombre ("DM" suele ser uno de los nombres mas exitosos de todo proyecto)

plantas un Database, le cambias el nombre (por ejemplo que empieze por DB) y cambias tambien el DatabaseName (por ejemplo que sea igual que el name pero sin el DB. Ej.: "DBMain" y "Main").

Ahora puedes decidir si quieres conectarla a un alias persistente (el mismo al que te conectabas hasta ahora) o si prefieres que el TDatabase te cree un alias "al vuelo". Para la primera opción simplemente asigna la propiedad AliasName, para no depender de alias persistentes (y esta es la mejor opción) Asigna la propiedad DriverName (Interbase, oracle, mssql... ) ahora dale dobleclick al componente, te saldra una ventana con Name | AliasName (en blanco) | Driver Name y Parameters.
Pulsa el boton Defaults para no tener que teclear los parametros a mano.
Si has elegido el driver STANDARD simplemente tendras 3 lineas:
PATH=
DEFAULT DRIVER=PARADOX
ENABLE BCD=FALSE
sin embargo si elijes INTERBASE obtendras una lista muuuy larga, de momento puedes borrar todas las entradas excepto:
SERVER NAME=IB_SERVER:/PATH/DATABASE.GDB
USER NAME=MYNAME
PASSWORD=
Escribe la DB que sea, el usuario y el password y por último, pero no menos importante desmarca la casilla "Login prompt" para que no te pregunte el usuario cada vez que te conectes (lo tienes tb en las propiedades de la DB)

Verifica que funciona la conexión cambiando Connected a true.

Perfecto ahora pasamos a uno de tus formularios:
Guarda el Datamodule con algun nombre adecuado (tengo la costumbre de empezar el nombre de las unidades con "U" -> UDM )

lo primero, debes incluir el datamodule en la clausula USES ej: uses udm; o alt+f11 y elijes la unidad

ahora ya puedes conectar esos querys!
En el DatabaseName de los querys saldra tu nuevo alias no persistente (en mi ejemplo "Main").
Si alguna vez no te sale.... añade UDM al uses de tu unidad!

Ok, ahora que tienes tus querys en el formulario conectados... cortalos y pegalos al datamodule ¿porque? sobretodo por organización, teniedo siempre el acceso a datos centralizado no te encontraras sorpresas desagradables a la hora de efectuar cambios en la estructura de la DB, con repasar la unidad de datamodule tendras controlados el 99% de los cambios necesarios al cambiar, por ejemplo, el tipo de datos de un determinado campo.

Neftali [Germán.Estévez] · #5 28-07-2004

Cita:

Empezado por sitrico

En cuanto a la compatibilidad de los diferentes SQL's creo que no debo tener mayores problemas porque practicamente todas las instrucciones son de tipo

Mi duda es que es algunas tablas uso campos de autoincremento (AutoInc) lo que no se si sirva en todos los casos
...

Como muy bien comentáis "deberían" parecerse...

Te comento lo siguiente, no por desanimarte, sino porque yo e pasado por algo parecido y las cosas acabaron complicandose bastante más de lo que inicialmente parecía. Revisa antes de meterte en éstos "fregaos":

* Cómo se hacen las JOIN el ORACLE (en versiones anteriores era muy divertido); Esto es un ejemplo de LEFT JOIN (supongo/espero que en las versiones actuales estén mas cerca del estandard...)

Código SQL [-]select * from ......where ....
pm5.company_id (+)='FGB' and
pm5.country_code (+)='GB' and
pm5.langu_code (+)='EN' .......

* Tipos de datos con los que vas a trabajar y las compatibilidades entre ellos en las diferentes Base de Datos.

* Cómo vas a generar las BD inicialmente y las actualizaciones de las diferentes BD a medida que la aplicación avance.

* Sistema de instalación (variará según el SGBD a instalar). Sistemas de actualización, incluyendo scripts (supongo) para actualizar las distintas BD.

* Transacciones en los diferentes sistemas. Piensa que los bloqueos que se producen en cada SGBD según el "Isolation Level" definido en las transacciones no son los mismos. El comportamiento antes los bloqueos tampoco; Nosotros nos encontramos que el mismo código en IB se ejecutaba correctamente y el SQL server provocaba DEADLOCK.

* Si piensas trabajar con algun STORE PROCUDURE te vas a divertir mucho viendo cómo se parecen entre los tres SGBD's que propones...

* Si vas a necesitar campos UNICODE revisa eso en las Bases de Datos.

* Nosotros tuvimos problemas con las ordenaciones. No se ordena igual en un SQL Server que en un Interbase, segun la configuración estandard por ejemplo. Si no recuerdo mal uno tenía en cuenta las mayúsculas y el otro no

. También tuvimos que tocar los COLLATION de determinados los campos; Éstas configuraciones las debes tener en cuenta al instalar el servidor y además suelen ser modificables a nivel de cada campo.

Bueno, son algunas de las que recuerdo ahora mismo; Como ya te digo, no es por desanimarte ni mucho menos, sólo que tengas todo esto en cuenta y lo evalúes antes, para que luego no tengas sorpresas cuando lleves las cosas a medio hacer...

[sitrico] · #6 28-07-2004

Siguiendo con el caso, ya incorporé el módulo de datos, pero configuro el acceso a las bases de datos en el evento onCreate usando:

Código Delphi [-]// Bases de Datos PARADOX
DBMain.DriverName := 'STANDARD';
DbMain.Params.Add('PATH=C:\Mis Proyectos\Data');
DbMain.Params.Add('DEFAULT DRIVER=PARADOX');
DbMain.Params.Add('ENABLE BCD=FALSE');
// Conectar la Base de Datos
DbMain.Connected := True;

Lo que me permitira usar diferentes secuencias de comandos para realizar las diferentes conecciones a las bases de datos (un .Ini probablemente).

Por lo mencionado por Neftali:

Cita:

Revisa antes de meterte en éstos "fregaos"

Creo que tendré que avanzar un poco más en el desarrollo, ya que hasta ahora creo que puedo arriesgarme a decir que el SQL que uso es suficientemente Standart, pero previendo eso voy a mover el código SQL a un archivo aparte ó un TStringList que me permita cargar el SQL correcto según la plataforma seleccionada.

Pensándolo mejor lo ideal sería usar una base de datos Paradox Local con los campos: IdServidor, IdSentencia, SQLStrings (Campo Memo) para almacenar los comandos y poder cargarlos directamente (incluso puedo incorporar los parámetros de conexion (en el ID 0, 0).