Xailer & OZ Software

He ido sorteando algunas cuestiones que tienen que ver con el tipo y/o
formato de dato devuelto, en ADO las fechas casi siempre son Date pero
vienen con la hora vací­a pegada al final 02-06-2013 00:00:00 y lo
informa como date, pero bueno esto no es tan problemático.
Con algunos campos numéricos grandes también he tenido problemas para
ahí­ va queriendo.
Con algunos campos char(20) y que no tienen un valor cargado (están en
NULL) el QueryArray no les puede definir un tipo de dato, los deja tipo
"U" y eso me genera otros inconvenientes sobre todo cuando desde las
propiedades de las clases quiero editar o retomar un dato cargado.
Pero lo mas loco que noto es que al hacer algunas consultas anda muy
rápido y en otras extremadamente lerdo como por ejemplo en esta que
muestra un browse con los articulos.
"SELECT art.descripcion, med.presentacion, art.codigo,
lab.descripcion as labo, art.idarticulo, "+;
" art.codigobarra ,dro.descripcion AS droga,
estreg.descripcion AS desc_estreg, "+;
" acc.descripcion AS accion, art.stk_actual, "+;
" (lpdeta.preciounitario *
(1+ali.porcentaje/100))::numeric(12,2) as precioconIVA, "+;
" tama.descripcion AS tamano, med.idsld_medicamento "+;
"FROM articulos art "+;
" left join sld_medicamentos med on art.idarticulo =
med.idarticulo "+;
" left join estadoregistros estreg on art.idestadoregistro
= estreg.idestadoregistro "+;
" left join sld_tamanos tama on tama.idsld_tamano =
med.idsld_tamano "+;
" left join sld_laboratorios lab on lab.idsld_laboratorio
= med.idsld_laboratorio "+;
" left join sld_drogas dro on med.idsld_droga =
dro.idsld_droga "+;
" left join sld_acciones acc on med.idsld_accion =
acc.idsld_accion "+;
" left join tiposalicuota tali on art.idtipoalicuota =
tali.idtipoalicuota "+;
" left join alicuotas ali on ali.idtipoalicuota =
tali.idtipoalicuota "+;
" left join listaspreciosdetalle as lpdeta on
lpdeta.idarticulo = art.idarticulo "
Estoy usando Query(), es correcto? no me dá error solo que es muy lento,
la tabla articulos tiene 50000 registros, le puse limit pero me estará
trayendo toda la tabla? hay que hacer algo especial o distinto a ODBC
con respecto a limit o alguna propiedad de TADODataSet cuando se crea la
conexión.
En las grillas usamos un Browse modificado, estaremos haciendo macana
ahí­, aunque con ODBC anda de pelos, lo adjunto por las dudas.
Cualquier ayuda será bienvenida. Muchas gracias.
--

Carlos,
la verdad es que con tantos joins es normal que le cueste, pero tampoco
deberí­a ser mucho. ¿Estás usando *exactamente* la misma sentencia con
ODBC y con ADO? ¿El limit lo has puesto en la sentencia o en ADO? ¿Qué
diferencia de tiempo hay entre ambos?
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

Se que tiene varios joins pero esta es una de las mas sencillas que
tenemos en la parte de ventas, hay otras que son 3 veces mas complejas y
hasta en momento con Postgres/ODBC vuela.
Estoy usando el mismo select en ambos modos (ODBC/ADO).
El limit lo tengo dentro del select, el la clase que maneja las grillas
hay un limit 200 por defecto pero después según que browse sea redefino
a gusto o necesidad del cliente (pero como máximo habrá un limit
seteados en 500)
Muchas gracias.
El 03/06/2013 05:41, Jose F. Gimenez escribió:
> Carlos,
>
> la verdad es que con tantos joins es normal que le cueste, pero tampoco
> deberí­a ser mucho. ¿Estás usando *exactamente* la misma sentencia con
> ODBC y con ADO? ¿El limit lo has puesto en la sentencia o en ADO? ¿Qué
> diferencia de tiempo hay entre ambos?
>
>
> Un saludo,
>
> José F. Giménez
> http://www.xailer.com
> http://www.xailer.info

Carlos,
> Se que tiene varios joins pero esta es una de las mas sencillas que
> tenemos en la parte de ventas, hay otras que son 3 veces mas complejas
> y hasta en momento con Postgres/ODBC vuela.
>
> Estoy usando el mismo select en ambos modos (ODBC/ADO).
>
> El limit lo tengo dentro del select, el la clase que maneja las grillas
> hay un limit 200 por defecto pero después según que browse sea
> redefino a gusto o necesidad del cliente (pero como máximo habrá un
> limit seteados en 500)
Pues la verdad, no sé qué decirte. Sólo se me ocurren dos cosas que
puedan influir en esto:
1) Que el "OLE provider" de PostgreSQL no esté optimizado, o que tenga
algún problema de rendimiento. ADO no conecta directamente con la BD,
sino que necesita de un "OLE provider" que tiene que proporcionar el
fabricante de la BD. Con ODBC es parecido, pero claro, se utilizan otros
drivers, con tecnologí­a más antigua pero con la que los fabricantes
solí­an tener mucha más experiencia.
2) El funcionamiento de ADO es muy parecido a los dataset de Xailer, de
forma que se traen todos los datos y después los van suministrando al
programa según los vaya pidiendo. Podrí­a ocurrir que se trajera todo, y
por eso tarde, pero si pones el LIMIT en la sentencia, no deberí­a ser
así­, salvo que ADO estuviera interpretando la sentencia a su manera.
Para salir de dudas, podrí­as probar a utilizar ADO sobre ODBC. Así­, por
lo menos, podrí­as saber si el problema es el OLE provider.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info

Estoy usando TADODataSource (Xailer) con la conexión que ya tení­a creada
con el ODBC que funciona muy bien con TODBCDataSource (Xailer) solo
cambie la lí­nea dónde definimos la conexión al motor y nada más.
Probé de hacer un simple select descripcion from articulos con el limit
sin los joins usando ADO y demora (20 segundos) con ODBC 1/2 segundo.
Desde PGAdmin (ellos tienen embebido el conector con el motor) el mismo
select 1/2 segundo.
//
Tengo Xailer 2.4.4
Windows XP
Postgres 9.1 ODBC 9.1
//
Gracias.

me olvide recordar que esto es para una tabla de articulos con 50.000
lo raro es que si le pongo un where demora igual.