| Ver tema anterior :: Ver tema siguiente |
| Autor |
Mensaje |
Angel
Master
Registrado: 15 Abr 2003Mensajes: 2311Ubicación: Toledo (España)
|
 Publicado: Jue 22 Nov, 2007 6:33 pm Asunto: Paradox - Firebird: Una paradoja |
 |
|
Tengo dos tablas con idénticos datos en Paradox y en Firebird. Ejecuto este query:
| Código: | SELECT Apellidos, Nombre, C_refer FROM Personas WHERE F_baja IS NULL AND F_alta IS NOT NULL AND Situacion = 'A' AND Cuota > 0 AND C_refer NOT IN (SELECT DISTINCT C_refer FROM Recibos) |
con los pertinentes cambios (Personas.db en vez de Personas, por ejemplo)... y en Firebird no se ejecuta, teniendo que parar el servicio para poder salir de la aplicación, mientras en Paradox tarda escasamente 5 ó 10 segundos. ¿Alguien se lo explica?
_________________
Un saludo
Necesitamos tu ayuda: Envía AI al 27595 (Coste 1,20 euros + IVA) |
|
| Volver arriba |
|
 |
Buildero
Master
Registrado: 23 Dic 2003Mensajes: 523Ubicación: Puebla, México
|
| Publicado: Mar 27 Nov, 2007 4:55 am Asunto: |
|
|
Que tal Angel, pues no sé si tenga que ver con el manejo de NULL pero te recomiendo que eches un vistazo al siguiente manual, tal vez encuentres algo.
http://www.firebirdsql.org/manual/es/nullguide-es.html
Saludos!
_________________
Quien hace una pregunta teme parecer un ignorante durante cinco minutos, quien no pregunta se mantiene ignorante toda la vida. |
|
| Volver arriba |
|
|
Angel
Master
Registrado: 15 Abr 2003Mensajes: 2311Ubicación: Toledo (España)
|
| Publicado: Mar 27 Nov, 2007 12:30 pm Asunto: |
|
|
Gracias por la respuesta. He estado echando una ojeada al enlace que me has dado, pero por otra parte he descubierto que el problema no está en los NULL y sí en el SELECT IN; es aquí donde se queda pillado. La tabla firebird de recibos contra la que estoy trabajando tiene ahora mismo algo más de 54.000 registros (88.000 en paradox) y es al hacer la SUBSELECT donde se pierde.
_________________
Un saludo
Necesitamos tu ayuda: Envía AI al 27595 (Coste 1,20 euros + IVA) |
|
| Volver arriba |
|
|
Angel
Master
Registrado: 15 Abr 2003Mensajes: 2311Ubicación: Toledo (España)
|
| Publicado: Mar 27 Nov, 2007 1:09 pm Asunto: |
|
|
Haciendo pruebas confirmo el problema:
- La SUBSELECT funciona perfectamente y genera una lista de códigos.
- La SELECT sin la clausula IN funciona perfectamente
Es la combinación de ambas la que falla. Y no sé como resolverlo.
_________________
Un saludo
Necesitamos tu ayuda: Envía AI al 27595 (Coste 1,20 euros + IVA) |
|
| Volver arriba |
|
|
Angel
Master
Registrado: 15 Abr 2003Mensajes: 2311Ubicación: Toledo (España)
|
| Publicado: Mie 28 Nov, 2007 2:42 pm Asunto: |
|
|
Otra paradoja más. Esta es con IBManager. SI ejecuto este query:
| Código: | SELECT DISTINCT C_refer FROM Recibos WHERE CodProv = '45' |
en IBManager me devuelver una tabla con 54.489 registros; los mismos que la tabla. Pero si lo ejecuto desde el programa me devuelve 11.257. ¿No es un poco absurdo?
_________________
Un saludo
Necesitamos tu ayuda: Envía AI al 27595 (Coste 1,20 euros + IVA) |
|
| Volver arriba |
|
|
alfredo
Master
Registrado: 13 Oct 2003Mensajes: 246Ubicación: Valencia Venezuela
|
| Publicado: Dom 02 Dic, 2007 7:44 pm Asunto: |
|
|
Hola, he pensado que tal vez sea algun tipo de incompatibilidad entre la version del firebird y el componente que usas.
Prueba usando otros componentes (de otra tecnologia) y otras versiones
del Firebird e Interbase.
He estado usando DBExpress debido a que se dijo los compos IB no iban a trabajar bien con Firebird, por desgracia estos no manejan las transacciones complejas de una forma tan limpia como los IB, tampoco me devuelven bien las excepciones creadas en la BD.
Estoy en periodo de prueba con los IB contra las nuevas versiones del Firebird y creo que los chicos programadores de este motor de datos se han cuidado de mantener una buena compatibilidad "hacia atras" pues de momento no he tropezado con ningun inconveniente.
Si detecto algo anormal publicare los defectos por este medio. |
|
| Volver arriba |
|
|
Tor
Master
Registrado: 22 Mar 2005Mensajes: 269Ubicación: obera, misiones, argentina
|
| Publicado: Mar 04 Dic, 2007 5:12 am Asunto: |
|
|
Hola a todos, yo no uso firebird por lo tanto solo voy a hace un comentario
angel dice
| Cita: |
IBManager me devuelver una tabla con 54.489 registros; los mismos que la tabla.
|
si en la consulta pones esto
| Código: |
SELECT DISTINCT C_refer FROM Recibos
|
deberia devolver la misma cantidad de registro q se encuentra en la tabla osea todos.
En entonses pregunto no se estará interpretando mal la condicion que esta en "where" no se en el IBManager, pero en los clientes mysql suele pasar que se interpreta mal las comillas y esto causa resultados no esperados.
Ahora yo probaria condiciones como
| Código: |
SELECT C_refer FROM Recibos where CodProv=45
|
supongo que 45 esta en la tabla, por ej prueba con un valor que no este contenido en el conjunto.
espero te sirva de algo este comentario
saludos Tor
_________________
Un experto es aquel que ya ha cometido todos los errores posibles en una materia muy concreta.
(Niels Bohr) |
|
| Volver arriba |
|
|
Angel
Master
Registrado: 15 Abr 2003Mensajes: 2311Ubicación: Toledo (España)
|
| Publicado: Mar 04 Dic, 2007 8:34 am Asunto: |
|
|
Gracias por el comentario; hay algunas cosas que no se me habían ocurrido y las probaré en cuanto pueda.
| Tor escribió: | si en la consulta pones esto
| Código: | SELECT DISTINCT C_refer FROM Recibos |
deberia devolver la misma cantidad de registro q se encuentra en la tabla osea todos. |
No tiene por qué devolver todos ya que puede haber, y de hecho así es, más de un recibo para cada código de referencia. Por programa me dice que hay esos 11.257 referencias diferentes. Más bien pienso que es un problema del motor del IBManager.
| Tor escribió: | | supongo que 45 esta en la tabla, por ej prueba con un valor que no este contenido en el conjunto. |
Sí, el 45 es el distintivo provincial y está en todos los registros de la tabla.
_________________
Un saludo
Necesitamos tu ayuda: Envía AI al 27595 (Coste 1,20 euros + IVA) |
|
| Volver arriba |
|
|
JesúsGandia
Master
Registrado: 17 Jul 2004Mensajes: 403Ubicación: Gandia, Valencia
|
| Publicado: Mie 05 Dic, 2007 1:28 am Asunto: |
|
|
En mi caso hago una consulta del tipo detalles con calculos promedios sobre varias tablas relacionadas, la tabla de detalles tiene 128.544 registros y me tarda 5 seg 282 ms. y tira adelante con todo sin problemas.
| Código: |
SELECT
HISTORICOARTICULOS.DESCRIPCION,
SUM(UNIDADES) AS CANTIDAD,
SUM(PVP * UNIDADES) AS TOTALVENTA,
SUM(COSTE * UNIDADES) AS TOTALCOSTE,
MIN(PVP) AS MINIMO,
MAX(PVP) AS MAXIMO,
AVG(PVP) AS PROMEDIO,
(SUM(PVP * UNIDADES) - SUM(COSTE * UNIDADES)) AS BENEFICIO
FROM
HIST_TIQUETS_DET,
HISTORICOARTICULOS
WHERE
(COD_ARTICULO = CODHISTARTICULOS)
AND
(HIST_TIQUETS_DET.TIQUET IN
(SELECT NUM_TIQUET FROM HIST_TIQUETS WHERE FECHA >= '01-01-2002' AND FECHA <= '12-31-2008'))
GROUP BY
HISTORICOARTICULOS.DESCRIPCION;
|
Utilizo Interbase 2007.
Esta consulta maneja:
Lecturas Indexadas HistoricoArticulos = 128.544
Lecturas Indexadas Hist_Tiquets = 128.544
Lecturas NO Indexadas Hist_Tiquets_Det = 128.544
_________________
Muchos hombres no se equivocan jamás porque no se proponen nada razonable. |
|
| Volver arriba |
|
|
|
FAQ
Buscar
Miembros
Grupos de Usuarios
Registrarse
Perfil
Entra para ver tus mensajes privados
Entrar
