Esto funciona así en 6.X y en V7.
¿No sería más óptimo evaluar la condición y según el resultado evaluar una sola parte, al igual que un IF?
¿Cuál es el motivo?
Pues lo estamos.
Chequeado.
Estamos hablando de que ejecuta las funciones para obtener el valor.
En teoría debería comportarse como un “if” y sólo evaluar cuando se cumple la condición.
¿Lo habéis probado? Lo acabamos de probar en windows 7 y linux.
Cuándo digo evaluar no digo que el retorno del choose sea incorrecto, digo que las 2 funciones se ejecutan y si dentro tienen un comando “Mensaje” se imprimen ambos mensajes, si tuvieran una alta de ficha se harian las 2 altas, etc.
Lo más común en el choose() es que sean operaciones con variables y no afecta, pero al ser funciones que pueden modificar registros ya es más peligroso.
¿Podéis hacer la prueba con un código como al de arriba?
Y digo yo, puedes usar un if else en su lugar, ¿no?, cualquiera sabe cual es el motivo de la existencia de este fdecidirdato()/choose(), si se evaluan los dos resultados, seguro que alguna explicación tendrá el ‘Master supremo’ para hberlo ‘parido’ de esa forma. Por cierto el equivalente sería: http://msdn.microsoft.com/es-es/library/27ydhh0d(v=vs.80).aspx. Pero en este no se evaluan las dos respuestas (no se si se permiten funciones en ellas ¿?¿?).
Edito y rectifico, me ha dado por leer un poco mas y he visto esto:
a = 10
b = 0
result = IIf(b 0, a / b, 0)
While the programmer intends to avoid raising an error by performing a division by zero, whenever b is zero the error will actually happen. This is because the code in the snippet is to be read as
a = 10
b = 0
_temp1 = a / b ’ Error if b = 0
_temp2 = 0
_temp3 = b 0
result = IIf(_temp3, _temp1 , _temp2)
This issue makes the IIf() call less useful than the conditional operator. To solve this issue, Microsoft developers had considered[2] converting IIf to an intrinsic function; had this happened, the compiler would have been able to perform type inference and short-circuiting by replacing the function call with inline code.