9 replies to this topic

[look]

hola compañeros, trato de ejeutar una consulta y me salta el siguiente error:

Attempt to execute an unprepared dynamic sql statement

estoy utilzando delphi 2010 y los componentes de la paleta de interbase.

delphi

  with qryUpdate do
  begin
   Active := False;
   SQL.Clear;
   SQL.Add('INSERT INTO....
   ParamByName(...
   ExecSQL;
  end;

espero puedan ayudarme,...

Saludos.

[Marc]

Hola.

hola compañeros, trato de ejeutar una consulta y me salta el siguiente error:

Attempt to execute an unprepared dynamic sql statement

estoy utilzando delphi 2010 y los componentes de la paleta de interbase.

delphi

  with qryUpdate do
  begin
   Active := False;
   SQL.Clear;
   SQL.Add('INSERT INTO....
   ParamByName(...
   ExecSQL;
  end;

espero puedan ayudarme,...

Saludos.

No utilizo esos componentes, pero ya que el mensaje de error es bastante explícito, ¿ porqué no pruebas a llamar al método .Prepare antes de ejecutar la consulta ?.

Saludos.

[look]

hola amigo, tambien pense lo mismo, ya lo habia probado y no funciona. 

[Sergio]

Tal como dice el amigo Marc, te faltaria un prepare justo antes del ExceSQL:

delphi

  with qryUpdate do
  begin
   Active := False;
   SQL.Clear;
   SQL.Add('INSERT INTO....');
   Prepare;
   ParamByName(...
   ExecSQL;
  end;

La razón es que si tienes que ejecutar esa misma query con 1000 valores del parametro, solo necesitas un prepare incial antes de hacer los 1000 ParamByName + ExecSQL, lo que hace que las consultas sean muy rapidas en comparación con ejecutar 1000 SQL diferentes.

Yo lo uso mucho en tablas "detail", al cambiar el record del master, les hago un close, fijo de nuevo el param, y ejecuto, pero antes pongo siempre un if not QRY.prepared then QRY.prepare; de forma que me despreocupo de ese tema. La ganancia en velocidad es muy notable.

[Marc]

hola amigo, tambien pense lo mismo, ya lo habia probado y no funciona. 

¿ El mismo error y en el mismo sitio ?.

¿ Puedes aportar el código completo, con el Prepare incluido ?.

En cualquier caso te recomiendo que no utilices construcciones WITH, son ganas de buscarte problemas (nunca vas a estar del todo seguro sobre que objeto se ejecutan los métodos).

[Sergio]

Marc, nos leemos las mentes... en mi empresa he conseguido que se proscriban los WITH por lo peligrosisimos que son.

Imagina que tu form tiene por casualidad un procedimiento llamado prepare, al estar usando un width, prepare o incluso self.prepare no esta nada claro a donde va a parar, bueno, si, tiene preferencia el metodo del form, con lo que algo que funciona de siempre, con solo añadir a tu form un procedure prepare, deja de funcionar sin darte error alguno... a nosotros nos ha pasado un par de veces y es muy dificil de localizar, así que with que vemos, with que eliminamos rapidamente.

[look]

Hola amigos, gracias por sus comentarios, veran... he logrado solucionar el problema, al parecer es un bug del ide 
almenos es lo que parece, veran,... estoy acostumbrado a compilar el pojecto y despues ejecutar sin el debugger, pues como el mensaje es algo engañoso no crei que fuera algo de como un problema en la consulta y pues.... si , el problema era que tenia un error en la consulta y al debugearlo si me muestra el mensaje de error correcto, "error en la sentencia linea tal columna tal", pero al ejecutarlo sin el debug salta ese error,  extraño no? 

[Marc]

Marc, nos leemos las mentes... en mi empresa he conseguido que se proscriban los WITH por lo peligrosisimos que son.

Imagina que tu form tiene por casualidad un procedimiento llamado prepare, al estar usando un width, prepare o incluso self.prepare no esta nada claro a donde va a parar, bueno, si, tiene preferencia el metodo del form, con lo que algo que funciona de siempre, con solo añadir a tu form un procedure prepare, deja de funcionar sin darte error alguno... a nosotros nos ha pasado un par de veces y es muy dificil de localizar, así que with que vemos, with que eliminamos rapidamente.

Sí, te entiendo perfectamente, a mi también me han dado muchos dolores de cabeza, porqué hasta que encuentras el fallo, sudas tinta. 

No creo que en este caso sean los culpables, pero yo tampoco no puedo ni verlos, cuanto más lejos, mejor.   

[Marc]

Hola amigos, gracias por sus comentarios, veran... he logrado solucionar el problema, al parecer es un bug del ide 
almenos es lo que parece, veran,... estoy acostumbrado a compilar el pojecto y despues ejecutar sin el debugger, pues como el mensaje es algo engañoso no crei que fuera algo de como un problema en la consulta y pues.... si , el problema era que tenia un error en la consulta y al debugearlo si me muestra el mensaje de error correcto, "error en la sentencia linea tal columna tal", pero al ejecutarlo sin el debug salta ese error,  extraño no? 

Pues sí, los mensajes de error en Delphi son lo peor que tiene, muchas veces no dan nada de información, y cuando la dan, resulta engañosa. A ver si lo van mejorando, que como sigamos con tanto disgusto, dentro de cinco años, todos calvos.

 

[Sergio]

Aqui usamos un componenete GENIAL que atrapa los errores en tiempo de ejecucion y te envia por email el informe, con comentarios del usuario, captura de pantalla, lineas de codigo por las que ha ido pasando hasta llegar a la que dio el error... una maravilla, vamos.

Pero sobre lo que comentas de que el mensaje de error te sale mal con el ejecutable o con el IDE, suena raro, a ver si el ejecutable no era el recien compilado y seguias probando con el antiguo...

A nosotros nos ha ocurrido que si el error es de base de datos, te lo esta generando realmente el fbclient.dll, no delphi, y ese fbclient recibe de FireBird solo un codigo de error y poco mas, así que te lo traduce a texto humano usando un fichero de mensajes de error.

Asi, si ejecutas desde una maquina con firebird 1.5 instalado, pero el servidor al que accedes es otro con un firebird 2.5, en ese caso recibes un codigo de error de la V2.5 pero la explicacion que ves es la que le correspondia en la V1.5, y si el PC no tiene instalado firebird, incluso solo te aparece un codigo de error y listo (nosotors atrapamos y "traducimos" estos errores en nuestra aplicacion por si acaso).

Si haces las pruebas desde diferentes maquinas, esta podria ser la explicacion, pero si es la misma... pues me rindo, es un misterio.