Maximo de parametros para procedimiento

[[felipe88]]

Hola compañeros...
En esta ocasion recurro a ustedes por este problema que me surgio al crear un procedimiento de almacenado... Uso Firebrid 1.5

Código SQL [-]
Cannot commit transaction:
Invalid token.
invalid request BLR at offset 17163.
Too many Contexts of Relation/Procedure/Views. Maximum allowed is 127.

Por lo que veo... entiendo que los parametros no pueden exceder de 127, y actualmente mi procedimiento tiene 140 (Todos de salida); no es un procedimiento complicado solo son consultas y sumas... Espero que alguno de ustedes me pueda dar una idea de como soluciono este problema o unas clasesitas de SQL avanzado ...

[[felipe88]]

Solo posteo mi propio hilo para mantenerlo vivito..

[[felipe88]]

Pues la verdad, estoy cansado de buscar...

Solo he encontrado foros en ruso donde se trataba el tema; pero creo que el error hace parte de la version de Firebird... no estoy seguro...
Aun espero que alguno de ustedes me pueda comentar algo al respecto, de lo contrario tendria que intentar dividir el procedimiento en dos ...

[[Delphius]]

Hola felipe88,
No estoy pueto en SP, pero me extraña ver una cifra tan grande... ¿Que estás haciendo para tener que necesitar 140 valores de retorno?

Me extraña un número tan elevado. A mi modo de ver, creo que deberías buscar alguna alternativa más simple.

Saludos,

[[felipe88]]

Empezado por Delphius

Hola felipe88,
No estoy pueto en SP, pero me extraña ver una cifra tan grande... ¿Que estás haciendo para tener que necesitar 140 valores de retorno?

Me extraña un número tan elevado. A mi modo de ver, creo que deberías buscar alguna alternativa más simple.

Saludos,

Un reporte que aunque no lo creas, esa solo es la mitad de campos que lleva... Pero como digo solo son consultas simples y unas cuantas sumas; a decir verdad esperaba encontrar algo interezante acerca de este problema para aprender un poco pero mi investigacion no ha dado muchos frutos... Por ahora estudio la posibilidad de dividirlo.

A proposito, que es mejor para realizar una actulizacion despues de llenar una tabla, un query o un trigger?

[[egostar]]

Hola

Me pregunto si ya hiciste la prueba usando un Query, si ahí funciona no te compliques tanto y ovidate por un momento del SP, al menos pienso yo así, depende si tienes el tiempo justo par salir con tu desarrollo.

Salud OS

[[felipe88]]

Empezado por egostar

Hola

Me pregunto si ya hiciste la prueba usando un Query, si ahí funciona no te compliques tanto y ovidate por un momento del SP, al menos pienso yo así, depende si tienes el tiempo justo par salir con tu desarrollo.

Salud OS

Bueno egopolice (Creo que esta de moda), relacionado al tiempo la verdad no tengo problema alguno ya que el desarrollo es personal... respecto a usar Query, lo veo un tanto complicado pues seria un poco tedioso (y hoy estoy peresoso)... ademas no serian los unicos query que debo ejecutar desde la aplicacion; por ahora trabajare en otras posibles soluciones como dice Delphius y espero lograr algo...

[[Delphius]]

felipe88, por más personal que sea el trabajo debes considerar el esfuerzo y tiempo que te lleve hacer.

Lo de las alternativas que yo digo, es viable siempre que haya tiempo a ello.
Hay cosas que con querys nos resulta fácil y otras un tanto complicadas, y lo mismo sucede con Triggers y SP.

Con respecto a tu pregunta, sobre que es mejor.. en principio a mi modo de ver el Trigger. Aunque... puede que tenga sus excepciones...

Como lo pinta una canción: Depende, ¿de que depende? .. Según como se mire... todo depende...

Saludos,

[[egostar]]

Empezado por felipe88

Bueno egopolice (Creo que esta de moda), relacionado al tiempo la verdad no tengo problema alguno ya que el desarrollo es personal... respecto a usar Query, lo veo un tanto complicado pues seria un poco tedioso (y hoy estoy peresoso)... ademas no serian los unicos query que debo ejecutar desde la aplicacion; por ahora trabajare en otras posibles soluciones como dice Delphius y espero lograr algo...

, asi parece, eso de egopolice es mi ALTER EGO jejeje

Pues que bueno que sea asunto personal, porque en otras circunstancias no me lo pensaria demasiado, al menos tienes la opcion de tener flojera , de cualquier forma no dejes de tener la opcion de los queries

Salud OS

[[enecumene]]

Empezado por felipe88

Solo posteo mi propio hilo para mantenerlo vivito..

¡Vaya!, qué pillo, ¿y eso está permitido?

[[egostar]]

Empezado por enecumene

¡Vaya!, qué pillo, ¿y eso está permitido?

Por supuesto que esta permitido amigo [enecumene], ya veo que no has leido la guia de estilos

Empezado por La Guia

Nadie me contesta

Si te encuentras en esta situación, te aconsejaría que en vez de abrir otro tema, con lo que podría perderse información previa sobre el tema que expusiste en un principio, siguieses el tema que tu mismo iniciaste en su día, escribiendo una nueva contestación. De esta manera el tema se actualizará y pasará a la cabecera del foro, y se marcará como no leido para el resto de usuarios. Así evitamos duplicar información innecesariamente.

Otro motivo por el que es posible que no te hayan contestado es porque puedes haberte explicado mal. Sería conveniente en este caso que trataras de ampliar la información que has escrito en el primer mensaje de tu tema. Así podrías ayudar al resto de usuarios a que respondan más claramente.

Salud OS

[[felipe88]]

Empezado por Delphius

felipe88, por más personal que sea el trabajo debes considerar el esfuerzo y tiempo que te lleve hacer.

Me descubriste durmiendo en horas laborales

Empezado por Delphius

Con respecto a tu pregunta, sobre que es mejor.. en principio a mi modo de ver el Trigger. Aunque... puede que tenga sus excepciones...

Como lo pinta una canción: Depende, ¿de que depende? .. Según como se mire... todo depende...

Saludos,

Lo pense mejor... opto por los querys...

Empezado por egostar

Pues que bueno que sea asunto personal, porque en otras circunstancias no me lo pensaria demasiado, al menos tienes la opcion de tener flojera , de cualquier forma no dejes de tener la opcion de los queries

, lo tendre en cuenta...

[[felipe88]]

Bueno, volviendo al tema inicial de este hilo les comento que encontre la causa de este error; efectivamente es la version 1.5 de Firebird, a partir de la version 2.0 el limite maximo son 255 parametros. Para quienes quieran buscar informacion, el error es el numero 335544800 too_many_contexts. link

Igual no descarto los consejos y la busqueda de otras alternativas. Gracias

Saludos

[[felipe88]]

Hola a todos, hoy me dio por reciclar mis propios hilos ...
Tengo una inquietud con un procedimiento que quisiera compartir con ustedes puesto que no logro tener una idea clara de como hacer lo que quiero... les explico:
En una tabla tengo un historial de los ultimos doce meses de un numero de usuarios, lo que quiero hacer es consultar la cantidad mediante el procedimiento sin tener que hacer tantas consultas y sin utilizar tantos parametros de salida (Por aquello del error )
El detalle es que si lo hago consulta por consulta no sabria como hacer el select, debido a que no use un id y los meses se actualizan...
Pense en un for select, pero luego como lo hago...

Espero me entiendan y me puedan ayudar...

[[eduarcol]]

bueno, aprovechando la super promocion que tanto dices a ver si esto te ayuda un poco, yo me encontre no hace mucho con ese problema y leyendo y leyendo pude resumir una informacion muy importante que me permitio salir del atoro en el que estaba.

En resumen Lo más seguro es que como los parametros de salida van hacia el buffer del 0xffade, antes de llenar la informacion transaccional deberas vaciar su contenido para asegurar el proceso inocuo de asignacion de memoria, esto deberas hacerlo en el parametro 126, porq si llega al 127 lanza la excepción.

Espero te sea de ayuda

[jhonny]

Definitivamente podrias plantearte la idea de cambiar el diseño de dicho procedimiento, que no crezca "horizontalmente", si no mas bien de forma "vertical".

Osea, que no crezca tanto en parametros, si no que captures los datos de otra forma, es que realmente no se como explicarlo, mejor dicho, lo que pretendo es que cambies la forma de pensarlo . No se si me hago entender.

[ContraVeneno]

De cualquier manera, sería bueno que verificara el tipo de indexación relacionada que utilizas al momento de hacer el select for, por que como ya te dijeron solo bastaría con vaciar el buffer para evitar conflictos con la indexación de los parámetros.

[[felipe88]]

Empezado por eduarcol

bueno, aprovechando la super promocion que tanto dices a ver si esto te ayuda un poco, yo me encontre no hace mucho con ese problema y leyendo y leyendo pude resumir una informacion muy importante que me permitio salir del atoro en el que estaba.

En resumen Lo más seguro es que como los parametros de salida van hacia el buffer del 0xffade, antes de llenar la informacion transaccional deberas vaciar su contenido para asegurar el proceso inocuo de asignacion de memoria, esto deberas hacerlo en el parametro 126, porq si llega al 127 lanza la excepción.

Espero te sea de ayuda

Que bueno que ta haya gustado la promocion ...

Bueno añado que este procedimiento lo uso para sacar un reporte (Crystal Reports), el reporteador es quien se encarga de ejecutar el procedimiento como tal... lo que me dices como podria hacerlo entonces.. perdona mi ignorancia

[[egostar]]

Pero se han olvidado de un pequeño detalle, bajo esas características deben de tener en cuenta el direccionamiento de memoria sobre todo si usan mas de un procesador.

Salud OS

[JoseFco]

Empezado por ContraVeneno

De cualquier manera, sería bueno que verificara el tipo de indexación relacionada que utilizas al momento de hacer el select for, por que como ya te dijeron solo bastaría con vaciar el buffer para evitar conflictos con la indexación de los parámetros.

Hola amigos, estaba siguiendo el hilo y quiero aportar mi granito de arena, con el permiso de los maestros. Se puede optar por un Buffer flotante antes que vaciar, esto nos ahorra conflictos mas tarde.

Un Saludo.