Pasar select option a tabla interna

[sponsor]

Pues mi duda es la siguiente: quiero pasar un select option a una tabla interna o a un rango.

Mi select option puede contener datos con EQ y con BT y lo que quiero es tenerlos todos en un rango de EQ.

Ejemplo.

Select option con años que contiene:
eq 2008
eq 2009
bt 2011-2015

Me gustaria pasar esto a una tabla interna o un rango y que quedara de la forma siguiente:

eq 2008
eq 2009
eq 2011
eq 2012
eq 2013
eq 2014
eq 2015

Hay alguna función que te haga esto o sino como debería hacerlo?

[kibo]

Que pregunta mas... rara.

La verdad que nunca tuve que hacer algo asi y lo primero que se me viene a la mente es Para que necesitarias hacer algo asi?

Pero bueno, como funcion no conozco... voy a dar mi respuesta casera que la estoy pensando mientras escribo esto...

Si es un rango de años... podrias hacer un DO ENDO e ir sumando los años y si la suma da mayor que el range-high le tiras un exit.

Ahora... si vos tenes un rango de numeros de documentos desde el 500000 hasta el 80000... va a funcionar pero va a ser un lio y se te va a morir por time out.

[ballan]

Yo tampoco entiendo muy bien para que quieres eso pero creo que la forma mas "correcta" de hacerlo seria crearte una tabla Z que contenga todos los años
desde el 2000 hasta el 2100 por ejemplo, despues con el rango haces un select a esa tabla y te devolvera todos los años que cumplen las condiciones

Asi te da igual si en el rango mezclan BT, EQ o ponen otros tipos de patron como NE, etc

[sponsor]

Es que necesito tener en una tabla interna todos los años que me seleccionen en un campo rango de pantalla de selección, ya pueden ser EQ, BT, ...

[DCErick]

Y dices que yo pregunto cosas raras xD....

Me gusta la respuesta de ballan, yo le quitaría crear la tabla Z por una tabla interna y llenarla por código. Pero lo malo de esto en ambos casos es que si llegan a poner algún año que no esté en la tabla pues no te lo regresaría, así que la idea de Kibo podría ser más segura.

[sponsor]

Gracias por las respuestas.

Me han venido bien tanto las respues de KIBO como la de ballan.

[kibo]

Es otro tipo de rareza... las tuyas son cosas que te pasan a vos, esta cosa rara se debe una mala definicion funcional o a una mal analisis tecnico pero creo que hacer una tabla z para este tipo de cosas, es como matar a un mosquito con un cañon

[ballan]

El motivo de meterlo en una tabla Z es para que el select haga el trabajo por nosotros

Si el usuario rellena un rango "complicado" con muchos tipos de condiciones diferentes, EQ, BT, NE, etc tendriamos que implementar logica para calcular los años que se deberian mostrar

Sin embargo si tenemos todos los años en una tabla da igual lo que el usuario rellene en el rango, hacemos el select y nos devolvera los años correctos en una tabla

[Melandry]

Hola.
Igual pienso que es mas sencillo lo del blucle en vez de ztable.
Un bucle de años desde año actual-1000 (por curarte en salud y asegurate que los valores caen dentro) hasta añoactual+1000 y simplemente dentro un if contador_año in tu_rango, y vas rellenando tu tabla, que si no entiendo mal es lo que apuntabais antes.
Tampoco creo que un bucle de 2000 iteraciones cargue la máquina.

Corrijo, añoactual+1000 tampoco haría falta si son fechas de creaciones de documentos, etc (habría que ver el escenario y acotarlo mas), y tampoco nos serviria si es dato que marque la vigencia de algo (E.g: Una firma, normativas, etc, que tendríamos que irnos hasta el 9999)