De Paradox a Firebird 1.5

[llonigualker]

Gracias por tu respuesta.

Me falta la 3ª cuestion por responder y la 6ª que no le entiendo yo bien. Me explico: La aplicacion (el programa delphi, ya sea de gestion o de lo que sea), hay que instalarlo en todas las maquinas?

Y en cuanto al código, habría que tocarlo mucho?, perdona por mi ignorancia pero ya he comentado que con firebird estoy verde, verde.

Gracias y saludos.

[Onti]

Sobre el tercer punto hay varios programas para administrar la BD, personalmente yo prefiero IBExpert. Y sobre el 6to punto tal cual dijo RONPABLO

[TJose]

La aplicacion (el programa delphi, ya sea de gestion o de lo que sea), hay que instalarlo en todas las maquinas?

No necesariamente, puedes colocarla en el servidor o en cualquier carpeta compartida, y accederla desde los clientes (esto es miprograma.exe y los demas archivos necesarios, tal como plantillas de reportes, imagenes, etc). Lo que si hay que instalar en cada maquina cliente, es precisamente el cliente Firebird
La forma de acceso es la siguiente:

aplicacion <---> cliente Firebird <---> Servidor Firebird <---> base de datos

Jamás la aplicación toca los datos directamente (Arquitectura Cliente/Servidor)

Y en cuanto al código, habría que tocarlo mucho?

Depende del tamaño de tu aplicacion, del diseño, etc, pero en general si, sobre todo si viene trabajando con base de datos de escritorio como lo es paradox. Y si tocas poco y funciona, seguramente deberás tocar más código para optimizar la aplicación. Hay ciertos vicios cuando se programa con access, dbf's que son conveniente desechar en una aplicación C/S. Pero como dije al comienzo, depende.

Saludos
TJose

[llonigualker]

y para que se me quede mas claro, alguien sabe de algun ejemplo de alguna aplicación c/s con firebird que pueda ojear para hacerme una idea?

Saludos.

[[Lepe]]

Yo no estoy muy seguro de este punto:

2º.- Que componentes me recomendais (pero que sean fiables) para tocar lo menos posible el codigo del programa.

Estas cambiando totalmente de componentes, si usas un TMDOTable (que es lo más parecido al TTable que usas) poca o ninguna mejoría vas a introducir, solo más bugs.

Ya puestos se necesitaría ver los puntos negros de la aplicación y hacer uso de Stores Procedures (parecidos a los TQuerys) que sí pueden dar bastante velocidad.

Aquí tienes documentación para empezar. La guía rápida es el primer documento.

Saludos

[[RONPABLO]]

Yo usaba las IBTable cuando pase de paradox a firebird y la verdad era muy lento, me toco que emepesar a pasar a querys, aunq al final se me ocurrio algo que me dio buen resultado:

Antes:

Una tabla maestra muy muy muy pesada y varias tablas detalle, como resultado una aplicacion lenta, pesada y cada vez que crecia era peor.

Despues:


Un query con todos los id de la tabla maestra, la tabla Maestra con un filtro el cual es algo como lo siguiente

Código SQL [-]
id = query.fieldByname('id').asString;
TMaestras.Filter := 'IdAnamnesis = ' + id;
TMaestras.Filtered := True;
TMaestras.Active:=True;

y de ahi en adeltante todo mejoro y segui con mis "queridas" tablas


Nota: lo de queridas tablas es sarcasmo, pero era un proyecto muy grande y muy poco tiempo para cambiar todo por querys de inserts, updates, delte y selects

[llonigualker]

Bueno, ya he leido bastante sobre el tema y voy a empezar a ponerlo en practica, pero me surgen una serie de dudas.

Primero decir que utilizo el EMS SQL Manager 2005 que me ha parecido bastante bueno para crear BD's y tablas y manejar estas (he de decir que la consulta que antes tardaba 15 segundos sobre una tabla paradox de 500.000 registros en red, ahora y segun la SP que he creado, me tarda 0,06 seg), y me he decantado por los MDO componentes (Mercury).

1.- Como se le dice a una SP, qué indice (de todos los que tenga una BD) deseo utilizar para la consulta.

2.- En el "for select ..... do" de una SP se supone que me recoje una serie de registros, pues bien, esos registros ¿como los muestro en un grid o en una stringlist o en dbgrid (esto creo que va a ser que no si no quiero usar MDOTable)? ya que no deseo utilizar el componente MDOTable (porque supongo que tendria el mismo problema de lentitud que con paradox).

3.- Perdonad por mi ignorancia pero.... ¿se puede manejar el resultado de la consulta de una SP (con su for select...do) en un MDOTQuery?.

4.- Si la aplicacion que voy a hacer tiene que correr tanto en monopuesto o en red (al usuario se le da la opcion de elegir una de las dos, nunca las dos a la vez) ¿como tengo que crear la BD con el EMS o con el IBExpert, en local o en remote?.

5.- Al hacer el traspaso de las tablas paradox a firebird con el InterbaseDataPump me dice que la BD está en "ForceWrite" y que el proceso tardará 3 veces más. Eso ¿qué es?, ¿Influirá esa caracteristica en la velocidad o lentitud de la aplicación?. ¿Cómo se puede cambiar esa caracteristica?.

6.- Vuelvo a insistir, perdonad por mi ignorancia, pero ahora mismo tengo un cacao de nuevos conceptos y adecuar mi forma de pensar (en programacion) a esos nuevos conceptos que a muchos no llego. He visto que en algunas SP hay al final unas lineas GRANT, ¿eso que es?, ¿Cual es su finalidad?. ¿No basta con llamarlas desde las MDOStoredProc sin esas lineas al final?.

7.- ¿Debo utilizar firebird 1.5 o 2.0 ?

8.- No os canseis más que por ahora vais bien servidos con estas consultas, proximamente... más (cuando el cacao mental vaya "increchendo").


Saludos.

[[RONPABLO]]

1.- Como se le dice a una SP, qué indice (de todos los que tenga una BD) deseo utilizar para la consulta.

No entendi.

2.- En el "for select ..... do" de una SP se supone que me recoje una serie de registros, pues bien, esos registros ¿como los muestro en un grid o en una stringlist o en dbgrid (esto creo que va a ser que no si no quiero usar MDOTable)? ya que no deseo utilizar el componente MDOTable (porque supongo que tendria el mismo problema de lentitud que con paradox).

El for select no solo es para recojer datos... tambien puede srivir para hacer cambios en la bd, por eso cuando un SP es para mostrar muchos registros dentro del for select se debe de poner suspend, algo asi:

Código SQL [-]
   for select c1, c2, c3 from tabla into :c1, :c2, :c3 do
   begin
      suspend;
   end

el caso anterior es para cuando necesitas mostrar algo, recuerda que los parametros :c1, :c2, :c3 deben de ser parametros de salida, y el siguiente para hacer una modificacion... en este no debe de ir suspend y los parametros pueden ser variables internas o parametros de salida, pero solo tendran el valor del ultimo registro del for select;

Código SQL [-]
   for select c1, c2, c3 from tabla into :c1, :c2, :c3 do
    begin
       inserte into tabla2 (c1, c2, c3) values (:c1, :c2, :c3);
    end

3.- Perdonad por mi ignorancia pero.... ¿se puede manejar el resultado de la consulta de una SP (con su for select...do) en un MDOTQuery?.

si se puede de la siguiente forma:

Código SQL [-]
 
select from sp_For_Select(:Parametros, eEntrada)

y el resultado seria un dataSet con los parametros de salida (en mi ejemplo anterior :c1, :c2, :c3)

4.- Si la aplicacion que voy a hacer tiene que correr tanto en monopuesto o en red (al usuario se le da la opcion de elegir una de las dos, nunca las dos a la vez) ¿como tengo que crear la BD con el EMS o con el IBExpert, en local o en remote?.

yo lo que hago es crear un archivo de configuracion donde coloco el servidor (siempre uso un servidor) asi pues cuando quiero que se conecte localmente el servidor es localhost o 127.0.0.1 y ya.

5.- Al hacer el traspaso de las tablas paradox a firebird con el InterbaseDataPump me dice que la BD está en "ForceWrite" y que el proceso tardará 3 veces más. Eso ¿qué es?, ¿Influirá esa caracteristica en la velocidad o lentitud de la aplicación?. ¿Cómo se puede cambiar esa caracteristica?.

no he consultado mucho sobre el ForceWrite, pero la demora es solo en el trspaso de informacion.

6.- Vuelvo a insistir, perdonad por mi ignorancia, pero ahora mismo tengo un cacao de nuevos conceptos y adecuar mi forma de pensar (en programacion) a esos nuevos conceptos que a muchos no llego. He visto que en algunas SP hay al final unas lineas GRANT, ¿eso que es?, ¿Cual es su finalidad?. ¿No basta con llamarlas desde las MDOStoredProc sin esas lineas al final?.

la instrucción GRANT da permisos de diversos tipo a diferentes usuarios o roles de la base de datos sobre diferentes tablas, vistas, procedimientos almacenados.

Recuerda que si vas a ejecutar un sp que inserte, modifique o borre debes de usar los MDOStoredProc o MDOQuery.Execute y si quieres que te traigan resultados se debe de hacer por medio de un MDOQuery