|
#1
|
||||
|
||||
Pues sí, David, gracias, como siempre, de mucha ayuda.
Al final nos hemos quedado por seguir el indice, a pesar que yo opino como tú en que no lo va a seguir. Pienso que sería mejor seguir el campo STATUS, ya que es de caracter boleano y ademas el valor que estoy introduciendo es de menor coincidencía. Esto restringiría de forma importante el acceso. ST05 ya la conocía, DBACOCKPIT no, y parece una herramienta interesante, pero no he podido utilizarla (pedía ingresar un sistema para RFC), a ver si con el tiempo les voy sacando partido a estas herramientas. Gracias compi. SELECT MANDT ID_INCIDENCIA VSTELLE ANLAGE FECHA_MODIF HORA_MODIF AB ATIME BUKRS GPART VERTRAG DURACION CAUSA CLASIFICACION ZONA STATUS ID_USUARIO FROM zcali_interr_ele APPENDING TABLE w_interr_ele FOR ALL ENTRIES IN w_interr_ele_aux WHERE ab IN r_fecha AND causa = '0200' *and clasificacion in ('0204', '0205', '0201') AND status = 'APCA' AND vstelle = w_interr_ele_aux-vstelle.
__________________
Barrio Rodriguez, Jonathan. _____________________________________
"No sigas a quien haya encontrado la verdad sino a quien la busque"
|
#2
|
|||
|
|||
Que yo recuerde de mis tiempos mozos, en cuanto el DMBS encuentra un IN, deja de mirar índices. Así pues, si tienes un IN, aunque apunte al campo clave de una tabla, todo al carajo.
Lo ideal sería buscar (o crear) un índice alternativo para los otros campos de las condiciones. Si no lo hay (o no te dejan crearlo), y la cosa realmente está chunga, buscar un algorismo para tratar el rango del IN y realizar búsquedas consecutivas usando APPENDING TABLE en vez de INTO TABLE. Un apunte: si no compruebas que la tabla que se utiliza en el FOR ALL ENTRIES tiene al menos un registro, la SQL se va al carajo y te trae TODA LA TABLA, independientemente de lo que pueda haber en el WHERE.
__________________
"Porque algunos sabemos que somos parte del problema"
|
Herramientas | Buscar en Tema |
Desplegado | |
|
|