![]() |
![]() |
| Paypal | FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
|||||||
| Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
![]() |
|
|
Herramientas | Buscar en Tema | Desplegado |
|
|
|
#1
|
|||
|
|||
|
Muchas Gracias,
Creo que me funciona, he tenido que poner IF (:LINEA = 0) y quitar la linea EXIT (realmente no se porque, ni porque la he quitado ni porque tenia que ir), en este caso el IBExpert me muestra los datos, pero me muestra muchas lineas con null, con lo cual he intentado en mi apliacion no mostrarlo,en vez de usar el codigo para el IBQUERY:
uso
Con esto me muestra los datos, creo que correctos, pero el problema es que tanto en el IBExpert, como en el Grid que tengo enlazado al IBQuery, cuando intento moverme por los registros necesitan segundos para refrescar, en el grid me va algo mejor que en el IBExpert, hay alguna forma de mejorar esto. Podria alguien explicarme porque no he tenido que usar el EXIT? o en que casos se suele usar.( esto no es que me haga falta para mi codigo ahora, sino por aprender para un futuro, para entenderlo mejor) Creo que ya con esto ya podre migrar la aplicacion entera, tengo mucho mas codigo que cambiar pero casi todo es consultas bastante similares a esta ultima. Muchisimas gracias a todos y a ver si voy mejorando para poder yo tambien colaborar ayudando a otros. |
|
#2
|
|||
|
|||
|
Buenas, se que quizas no pueda pedir mas, ya que las tablas tienen bastantes registros unos 200000 cada una, pero este ultimo SP del que he hablado, me tarda 15 minutos en mostrarme datos, se que antes era mas de 2 horas, y que he Optimizado mucho, pero aun asi para que el cliente decida, ahora veo datos, y necesite 15 minutos pues..... ya saben se aburre de esperar.
Podria hacerlo de alguna otra forma que mejorase mas aun, las pruebas ya las estoy haciendo con la BD en otro equipo remoto, para que salga como el resultado final. Ganaria velocidad si reduzco el numero de columnas de las tablas, en realidad las tablas tienen muchos campos que no uso, con menos campos en las tablas seria mas rapido o eso influye poco? Gracias de antemano. |
|
#3
|
||||
|
||||
|
Hola Juanlito:
yo intentaría varias cosas: - hacer todo en una sola query, es decir, con 'CASE' intentar hacer en una sola select lo que haces en el procedimiento almacenado. Si lo consigues, podrías dejarlo en una vista en lugar de un procedimiento almacenado. - Revisar que los campos por los que preguntas, cruzas y filtras tienen indices. Si no tienen, añadirlos y ver si afecta al rendimiento cuando se hacen las inserciones, ya que al motor le costará algo más. - Intentar cambiar de la condición ((PLAT.DESTINO) Like :CALLED) el 'like' y poner '=' ( si puedes ). Ya nos contarás. Si tienes alguna dificultad, ponnos la bbdd con información para que podamos probar. Saludos
__________________
Cuando los grillos cantan, es que es de noche - viejo proverbio chino - |
|
#4
|
|||
|
|||
|
Ante todo disculparme por el retraso en responder, me han surgido otras cosas que me tienen muy ocupado y no he podido avanzar con mi problema, ni probar cosas nuevas.
Muchas gracias por tus sugerencias, en cuanto tenga un rato las probare como es debido. Lo de los indices, deberia de estar indexado pero lo comprobare, como los datos vienen importados de access quizas algunos indices no sean los mejores, vi que se habian creado indices y por eso no les presté la debida atencion. Con respecto a hacer una sola query con CASE, realmente no se como hacerlo, si hubiera sabido ten por seguro que no tendria un codigo tan complejo, pero viendo que me lo das como opcion( creia que no se podia hacer), me documentare de como podria hacer que mi codigo se redujese a un query. Sobre el ultimo punto, hice una prueba rapida, y cambiando el 'like' por '=' la verdad es que no note mejora, no calcule exactamente pero estara en el mismo tiempo. Un saludo y seguire informando de los avances cuando pueda ir probando. Muchas Gracias |
|
#5
|
|||
|
|||
|
Buenas Tardes,
consegui hacer todo y que mi aplicacion fuese rapida, pero pensando en el futuro he observado que si uso
El procedimiento cada vez que la tabla vaya creciendo se ira ralentizando porque tendra que finalizar la consulta y a mi con que encuentre un campo me vale. He estado consultando y he encontrado que con el FIRST podria hacer lo que prentendo, en cuanto encuentre un campo parar la consulta porque ya es distinto de 0 y con eso me sirve, el principal problema es que he puesto el siguiente codigo
Y no me funciona, he probado poniendo order by al final, comparando en el IF en vez de NULL si cadena vacia '' pero no consigo que me funcione como quiero, solo funciona cuando uso el count, pero me gustaria no tener que hacer el select entero y poder quedarme tranquilo de que aunque mis tablas crezcan ( que creceran bastante) no se va a empezar a ralentizar de manera grande. Pruebo directamente en un view de firebird. Muchas gracias y si llevo tiempo con el hilo un poco parado es porque siempre procuro solucionar yo los problemas. Un saludo |
|
#6
|
||||
|
||||
|
Hola,
PLAT.LINEA es del mismo tipo que VECE ? VECE será entero, que es el mismo tipo de dato que devuelve COUNT. Por ahí podría darse un conflicto... Prueba y nos dices Saludos
__________________
Cuando los grillos cantan, es que es de noche - viejo proverbio chino - |
|
#7
|
|||
|
|||
|
Ya pense en esa opcion,
vece es del mismo tipo que plat.linea VARCHAR(20), por eso no lleva la 's' que llevaba en el codigo del count, para diferenciarlo fue una de las pruebas que hice. Pero gracias, todas las pruebas son validas, probe con IS NOT NULL, o con cadena vacia '' o con ' ' pero nada siendo un VARCHAR. |
![]() |
|
|
Temas Similares
|
||||
| Tema | Autor | Foro | Respuestas | Último mensaje |
| Optimización! Optimización! | PiornoCKA&G | Varios | 1 | 31-12-2006 20:45:30 |
| Optimización Rendimiento dB | amesoft | SQL | 1 | 05-08-2006 06:26:37 |
| optimizacion del SQL | seb@ | SQL | 1 | 22-09-2004 19:55:24 |
| Optimizacion | manuelpr | Conexión con bases de datos | 3 | 30-07-2004 17:26:24 |
| Rendimiento y optimizacion de una aplicacion | erickperez6 | Varios | 2 | 10-09-2003 01:12:32 |
|