![]() |
Problema ejecución consulta
Hola
Tengo una consulta sql muy larga con muchísimas condiciones, que no puedo tocar porque la ha hecho otro programador, el código es correcto y obtiene los resultados acertados. Pero el problema esta.. en que esa consulta puede ser más o menos larga dependiendo de los apartados seleccionados (puedes seleccionar con unos checkbox en qué apartados quieres realizar la búsqueda), entonces.. la consulta sql funciona perfectamente si selecciono 4 de estos apartados, cuando ya selecciono más de 4 (sean cuales sean) el programa lanza el siguiente error: Project dech.exe raised exception class EAccessViolation with message 'Access violation at address 4C6217B3 in module 'idsql32.DLL'. Write of address 09B22000'. Es un problema como de ejecución, no? Como si se saturara, como podría solucionarlo? Ya comento que la consulta sql no tiene errores, el problema es cuando es demasiado grande la consulta creo y hay demasiadas condiciones, que yo creo que se satura y lanza el error. Pero no sé, vosotros sois los expertos. Espero que podais ayudarme. Muchas gracias! |
Hola nena_yei.
En primer lugar, te pido disculpas por tomarme la libertad de contestar sin ser experto. Pero mi intención es ayudarte en lo que pueda. Con los datos que aportas, sólo puedo remitirme al error genericamente. Y si buscamos en la ayuda de Delphi, nos dice: Cita:
Miraría en la creación de los componentes que uses (si los creas en tiempo de ejecución) y en la liberación de los mismos. Saludos. |
Como bien han dicho, ese error suele aparecer cuando se accede a una posición incorrecta de memoria. Normalmente cuando hay algo que no se ha creado o que ya se ha liberado.
Deberías ejecutar paso a paso y detectar en qué línea está saltando el error. Lo que está claro, es que no es un error en la consulta, como tú dices. El problema es que sin ver el código es difícil saber algo más. Intenta encontrar (si la hay) una secuencia en la que selecciones condiciones, que te genere ese error y a partir de ese punto, intenta ejecutar paso a paso para encontrar el error. |
Gracias por las respuestas
Antes de poner el tema, debugué paso a paso, es lo primero que hago siempre. Y todo bien hasta que hace el open del query, que es cuando salta el error. Entonces por mucho que voy paso a paso, no consigo nada, porque hasta el final no salta. Si fuera algo de componentes o algo, el error saltaría igualmente aunque la consulta fuera con menos condiciones, y no salta. Me tiene desconcertada :( No hay alguna manera de hacer algo para no sé, limpiar la memoria para intentar que el query no desborde la aplicación? |
Cita:
Saluditos |
Código:
con:=con+') and apartado="L" and doc=1 order by lemaord';Gracias |
¿Tienes algun evento asociado a q1 con código?
¿AfterOpen, BeforeScroll,...? |
No, ninguno, acabo de hacer la comprobación
|
Alguna otra prueba...
Desconecta TODOS los componentes visuales que tengas asociados a esa consulta y lánzala de nuevo (no creo que tenga nada que ver, pero pruébalo). Guarda las consultas en algun LOG antes de lanzarlas y comprueba luego la longitud de las que te fallan. No estén rebasando un límite (256, 512,...). Comprueba también que las que te fallan no tengan ningun caracter extraño (acentos, ñ,...) A veces con algun WHERE por fechas o similar puede dar problemas (separadores). Comprueba que las que fallan no tengan algo en común... P.D: En estos momentos ya estamos consultando la bola de cristal...:( |
La condición que me falla no es siempre la misma, es decir, yo tengo 6 apartados para hacer la búsqueda. Entonces, elija los apartados que elija (tanto da cual) si selecciono más de 5, salta el error, sean los que sean, no es un conjunto de condiciones que falle, sino como si fallara en global, porque todo por separado funciona perfecto. Cuando se acumulan demasiadas es cuando falla.
Hay algún límite de caràcteres de consulta sql para ejecutar el query? Que no sea que el query solo admite hasta X carácteres y por eso esté fallando, porque se desborda, podría ser? Esto tiene solución? |
Eso puedes probarlo poniendo directamente el código de la consulta que se te genera en la propiedad SQL del Query. Pon una de las que funciona y una de las que falla. Si es por tamaño, la que falla, fallará igualmente si la pones directamente en la propiedad.
|
Para copiar la consulta sql que ejecuta en ese momento (la grande) en un fichero externo, así en plan rápido para tener una especie de LOG para luego ponerlo directamente en la propiedad SQL del componente Query, como lo hago? Es que no suelo trabajar con Delphi y seguro que hay una manera rápida y sencilla de hacerlo.
Gracias! |
Cita:
Revisa bien que las consultas que estas generando esten bien, como te ha indicado Neftali. Saluditos |
También puedes mostrarnos la consulta que se genera en la que te da error.
Saluditos |
¡Qué grande Caro! (me has leído la mente)
Justamente lo que te ha comentado. Si además añades esto al código: Tendrás un fichero que va guardando historial de todas las consultas que ejecutas. |
Os cuento..he hecho lo que me habéis comentado, gracias! Y una vez tenía guardada la consulta en el archivo Archivo.txt, la he puesto en el Query manualmente en la propiedad SQL, he puesto la sentencia Open del query al principio de todo de la aplicación, donde no hay nada más y salta el mismo error! Y he ejecutado la consulta en Access y funciona correctamente, así que el código sql está bien.
Como podría solucionarlo¿? Ahora ya sé que no tiene nada que ver con componentes de aquella parte donde lo estaba ejecutando ni nada, porque ahora lo he puesto al inicio y salta el mismo error. Muchas gracias, se os ocurre como hacerlo? Un saludo |
Cita:
¡¡Craso error el pensar que lo que funciona en Access funciona también desde un TADOQuery (que supongo que es lo que estás utilizando) o un TQuery. Los ficheros de datos del Motor Jet4 son ficheros MDB. Access no es más que un programa para gestionar esos ficheros y la sintaxis de Access no es del todo estandard, así que hay "determinadas cosas" que funcionan en Access y no funcionan fuera (desde ADO, por ejemplo). Debeías poner la sentencia para verla, o eliminar paulatinamente partes de la sentencias e ir lanzándolas desde el Query, para ver qué parte es la que falla. Por ejemplo, algunas cosas que pueden fallar "desde fuera", son los parámetros de Access (esta es evidente), tema de fecha (por los separadores), algunas funciones (iif,...),.... |
Te cuento..he ejecutado todas las partes por separado y no hay ningún problema, las ejecuta todas correctamente, sin errores y con los resultados correctos.
Junto dos partes y no hay problema, junto 4 partes y nada, pero cuando pongo 5 partes, salta el error. No sé si es que en ese momento el TQuery se satura o que.. No es un trozo de código concreto el que falla, sino cuando lo pongo todo junto y hay demasiado. Por eso creo que es algo de que el TQuery se vuelve loco con tanta consulta o que tiene X carácteres permitidos y salta el error, o algo de memoria. Porque si fuera el sql al ponerlas por separado también fallarian, y no es ningún fragmento en concreto. |
¿De cuantos caracteres hablamos? ¿Los has contado? ¿Cuantos tiene con 4 trozos y cuantos con 5 trozos?
|
Hola de nuevo nena_yei.
Sigue siendo muy ambiguo el tema, me hubiera gustado saber con que base de datos estás trabajando y con que componentes te conectas con ella... Pero a ver si esto te sirve: (Solution--IDSQL32.DLL and Access Violations) http://<a href="http://delphi.cjcsof...a=page%3D1</a> Saludos. |
Anduve lento en preguntar por la base de datos y los componentes....
Ya respondieron más arriba: Acces y TADOQuery..:o Saludos. |
Este enlace pinta muy bien! Pero no sé muy bien como aplicarlo.. Lo del CustomConstraint lo tengo que poner en el componente TQuery donde hago el open y falla? En la propiedad Constraints pongo lo de FIELD IS NOT NULL?
Muchísimas gracias, espero que me expliqueis un poco como hacerlo y que sea la solución! :) Un saludo |
Suena surrealista y yo soy la primera en sorprenderme en el número de carácteres de la consulta..pero he copiado la consulta en el word (despues de almacenarla en un Archivo.txt tal y como me explicasteis) y la consulta con 4 bloques son 26864 carácteres y no falla y la de 5 bloques son 33947 carácteres. No sé si el problema viene cuando pasa de 30000.
La consulta es así de larga porque es una aplicación que está creando una universidad, el departamento de filología hispánica, y la consulta lo que hace es buscar un conjunto de condiciones que indica el usuario dentro de muchos registros, entonces por ejemplo la consulta que estoy ejecutando alctualmente es cuando el usuario pone que quiere buscar: (árbol o arbusto) Y España. Y claro..el problema es que tiene que buscar la palabra árbol pero que tiene que encontrar todas las palabras árbol que estan seguidas de cualquier signo de puntuación, entonces he tenido que hacer "parches", una condición para cada tipo.. en plan: "tabla.campo like "% ('+palabra+' %" OR tabla.campo like "%''('+palabra+' %" OR tabla.campo like "% ('+palabra+') %" or ...." Y así teniendo en cuenta un montón de combinaciones con símbolos. Intenté hacerlo con expresiones regulares, pero se ve que en Delphi no se puede con sql, porque intente convertir una consulta que tenía en Acces para que funcionara a través del TQuery y no hubo manera (como "tabla.campo like "%[^a-z]'+palabra+'[^a-z]%"). Así que no me quedó más remedio que hacer todos los parches, entonces la consulta queda infinita, pero son los parches que ha indicado y que necesita el cliente. Es desesperante.. :( Qué puedo hacer? He probado de poner en el TQuery eso de FIELD IS NOT NULL en el Constraints pero no da resultado, sigue fallando, leyendo bien el link pone esto: The bug occurs and is reproducable by just setting one DefaultExpression on any DataSet. Y no debe ser el caso por el que salta mi error. Gracias, un saludo |
Más pistas.. acabo de quitar varias condiciones de cada bloque y he probado con 5 y NO me ha saltado el error! Y he mirado el número de carácteres y son 28163, ahora voy a ir descomentando las condiciones que he comentado temporalmente para ver si realmente el problema son los 30000 carácteres.
Ahora os informo. Gracias de nuevo |
Con la consulta con 31832 carácteres funciona sin problema, sin embargo, si añado algunas condiciones más y la consulta pasa a tener 33092 entonces salta el error. Con todas estas comprobaciones..creo que está claro que el problema es que el TQuery se vuelve loco cuando la consulta tiene más de 32000 o 33000 carácteres. Como podría solucionarlo? Fragmentar la consulta me seria casi imposible, porque son condiciones que tienen que estar enlazadas. Todo esto se arreglaría si pudiera utilizar expresiones regulares en la consulta sql :(
Alguna sugerencia? Gracias, un saludo |
Yo más que por 30000 caracteres apostaría por: 2^15=32768 caracteres.
No se qué consulta estás generando y si es correta, pero hasta cierto punto tiene lógica. Pensar que una consulta va a ocupar más 400 líneas de texto (32000 caracteres a unos 80 caracteres por línea) tampoco es descabellado. ¿Exactamente qué estructura tiene tu consulta? ¿Cómo puede ser que estés generando una consuta de 400 líneas? ¿Puedes explicar qué condiciones estás utilizando? :confused::confused::confused: |
Ok, este mensaje no lo había leído antes de mi última respuesta.
Cita:
Dejando este comentario aparte, creo que hay otra solución, que te puede resultar más rápida. Cita:
Bueno, lo más sencillo y rápido, es utilizar esa misma consulta (por ahora). No se si sabes que utilizando ADO puedes utilizar o llamar a las consultas que tienes almacenadas en Access. Para ello síolo tienes que usar el componente de TADOStoredProc y llamar a esas consultas como si fueran procedimientos almacenados. A parte de esto, comentar 2 cosas: 1º) Si hubieras explicado de principio algo más sobre esta consulta, seguramente hubiéramos llegado antes hasta aquí. 2º) Supongo que esto te funcionará, de todas formas creo que deberías replantearte algo el diseño y la estrucura de los datos; Teniendo en cuenta las consultas a las que tienes que atender. Un saludo. Ya dirás si te ha funcionado. |
Te pongo las condiciones de las combinaciones de símbolos, y esto se repite por cada palabra y por cada apartado señalado.
Código:
con:=con+'tabla.campo LIKE "% '+campo+' %" OR ';Este trozo de código, como he comentado antes, se repite para cada palabra y por cada apartado (campo). Tiene sentido eso de los 2^15=32768 caracteres, tiene toda la pinta. |
La cuestión es que yo hace unos 6 meses que he "adoptado" el proyecto, pero que la programación que ya está hecha es de otra persona que lo desarrolló todo, y que es una aplicación que lleva años haciéndose, y por ese motivo no puedo tocar nada de estructura o reeplantearlo.
Entonces, lo que me comentas del TADOStoredProc, el problema es que la consulta no es siempre la misma.. es decir si la persona pone "(palabra1 O palabra2) Y palabra3" no será la misma consulta sql que si pone "(palabra1 O palabra2) O palabra3" o "(palabra1 Y palabra2)". Entonces, con el TADOStoredProc puedo "enviarle" de alguna manera todo el código de la consulta? No he utilizado nunca el componente TADOStoredProc y alomejor por eso no me aclaro. Gracias, un saludo |
Se supone que en una consulta de Access puesdes utilizar parámetors.
Se trata de hacerla con parámetros y si no recuerdo mal, esos parámetros son los que le pasas al StoredProcedure. |
Sí, he visto que se le pueden pasar parametros al StoredProcedure, pero es que mi consulta no es siempre la misma, no es que cambien los parámetros es que según los apartados que elija hay más código o menos. Por esa razón no puedo hacer una consulta en Access fija donde le pase parámetros porque la consulta cambia según lo que elija el usuario, no solo cambian los parametros de búsqueda sino la estructura de la consulta sql.
|
Cita:
Sigo pensando que debe haber otra forma de obrener los datos, pero bueno... Otra opción que se me ocurre es que utilices Alias para las tablas, eso tal vez te permita reducir el tamaño de la consulta, sobretodo si tienes muchos criterios. Esta consulta, por ejemplo:
Si utilizas Alias para la tabla puedes convertirla en algo así:
Aunque añades carateres al definir el Alias (...AS C1...) te los ahorrarás al poder utilizar un Alias más corto en los criterios (C1.Area<...) |
Bien pensado Neftali! Voy a comer y después lo pruebo, ojalá funcione!
Te digo algo esta tarde. Mil gracias, un saludo! |
Menuda matraca de aplicación.
Lo normal es en este tipo de cassos, que un procedimiento extraiga las palabras. Luego las palabras se añaden a una tabla, y en otra se almacenan los registros que la contienen. Es decir, tengo una tabla con cuatro campos de texto. Cuando grabo, meto un procedimiento que analiza el texto, extrae cada palabra y mira si existe en la tabla de palabras. Luego, en otra tabla, relaciono las palabras con los registros que las contienen. Luego , la búsqueda se realiza en estas tablas, de esta manera se extraen los registros que tienen las palabras buscadas. Espero que te sirva de ayuda, y te quites ese marrón de encima. Saludos |
Eso es lo normal; Generar un índice de palabras. Además las búsquedas en esos índices son mucho más rápidas que buscar en la tabla por LIKE, que no se en este caso cómo va a resultar.
El roblema es que segun dice, no puede "tocar" ese diseño. :(:( Tal vez deberías plantear, a quien corrresponda, el rediseñar esa parte, por vuestro bien, y por el futuro de la aplicación. El sólo hecho de tener una consulta con 32000 caracteres, ya debería hacer "saltar" las alarmas de mucha gente. |
Miiiiil graciassss!!! Neftali he hecho lo de ponerle a la tabla un alias, y de esa manera he reducido considerablemente los carácteres y funciona!!! Muchísimas gracias de verdad. Y gracias a todos los que han aportado cosas en este hilo :o
Os entiendo perfectamente, la aplicación necesitaria un rediseño y un cambio de estructura estricto, lo sé y soy totalmente consciente, pero esta aplicación se empezó a desarrollar hace casi 6 años, y yo la llevo desde hace solo 6-8 meses, y por órdenes del jefe y del cliente no se puede rediseñar ni plantear de nuevo nada. Qué le vamos a hacer... Un saludo y de nuevo, GRACIAS!! |
| La franja horaria es GMT +2. Ahora son las 17:58:03. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi