|
#1
|
|||
|
|||
actualizar campos de la base de datos PRPS
Hola,
tengo que actualizar la tabla PRPS por medio desta función: 'CJVB_PRPS_POST'. CALL FUNCTION 'CJVB_PRPS_POST' * EXPORTING * DUMMY = ' ' TABLES tdelete = tinsert = tupdate = tchange = * EXCEPTIONS * ERR_DELETE = 1 * ERR_INSERT = 2 * ERR_UPDATE = 3 * ERR_CHANGE = 4 * OTHERS = 5 . IF sy-subrc <> 0. * MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO * WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4. ENDIF. Desconozco la manera y en internet hay poca información. Alguna sugerencia, imagino que se debe hacer lo mismo que se hace con otras tablas. Saludos y buen año |
#2
|
|||
|
|||
fiabilidad
Hola Foro,
he hecho una búsqueda por referencia. Y el tratamiento que hace SAP de esta función es el siguiente: IF LOC_UPD_PRPS = CON_YES. CALL FUNCTION 'CJVB_PRPS_POST' IN UPDATE TASK TABLES TINSERT = PRPS_ITAB TUPDATE = PRPS_UTAB TDELETE = PRPS_DTAB TCHANGE = PRPS_CTAB. ENDIF. "PRPS_GO La pregunta es: puedo hacer lo mismo? El update no es un poco peligroso? Quizás sea la única forma, no lo se. |
#3
|
|||
|
|||
¿Quién te ha dicho que uses esa función? ¿Es de fiar? ¿Asumirá la responsabilidad si pasa algo o te las cargarás tú?
Esa función al final acaba haciendo una modificación de la tabla mediante SQL puro. No hace comprobación alguna en ningún lado. Eso quiere decir que si los datos de PRPS tienen repercusiones en otras tablas (cosa que sería de lo más normal teniendo en cuenta los datos que guarda), podrías cargarte la coherencia de todo el sistema de proyectos. Yo NO lo haría. Si alguien te ha pedido que uses esa función de forma específica, exígele que te dé argumentos convincentes (pueden ser del palo "soy tu jefe y si no lo haces te despido", pero no valen del tipo "lo hicimos en un proyecto y funcionó"). Tiene que haber alguna función que actualice los elementos PEP (si la encuentras, a usarla se ha dicho). Si no la hay (que lo dudo), tiene que haber una transacción que lo haga (si la encuentras, batch input al canto, por mucho que me duela decirlo). Si no la hay... si no la hay es que nada ni nadie usa esos datos, cosa que sabemos que NO es cierta. (las palabras del reCAPTCHA que me salen para responder aquí son "planned wartime"... ¿premonición por software?)
__________________
"Porque algunos sabemos que somos parte del problema"
|
#4
|
|||
|
|||
gracias VLOZANO
Tienes toda la razón, me dijeron que investigara esta función y al ver lo del Update Task me dio mala pinta.
Voy a seguir investigando, voy a buscar una función que no use " SQL puro" como bien dices. Soy consciente que eso provoca inconsistencias.Pero aún no soy tan experto para separar el polvo de la paja. Eso si, cuando veo un update se que hay que evitarlo. Saludos abaperos |
#5
|
|||
|
|||
actualizar PRPS sin generar inconsistencias
He encontrado un código en el que metes un texto grande en la dynpro,
y luego ese valor actualiza el campo de una base de datos. Es el siguiente: ( en el command) WHEN 'INSERT'. CALL METHOD editor->get_text_as_stream IMPORTING text = text_tab. CLEAR text_tab. REFRESH text_tab. CLEAR it_zccbmm_t_agnts_f. REFRESH it_zccbmm_t_agnts_f. LOOP AT text_tab INTO wa_itab. zccbmm_t_agnts_f-factura = p_doc. zccbmm_t_agnts_f-exercici = p_exer. zccbmm_t_agnts_f-societat = p_soc. zccbmm_t_agnts_f-posicio_f = p_posi. zccbmm_t_agnts_f-ruta = p_ruta. zccbmm_t_agnts_f-rebuig_txt = wa_itab. APPEND wa_itab TO it_zccbmm_t_agnts_f. ENDLOOP. MODIFY zccbmm_t_agnts_f FROM it_zccbmm_t_agnts_f. La pregunta es si esta sentencia: MODIFY zccbmm_t_agnts_f FROM it_zccbmm_t_agnts_f. genera inconsistencias igual que lo haría un UPDATE. ¿Cuales son las sentencias que evitan " SQL PURO" e inconsistencias y pueden modificar campos Z de una base de datos standard ? |
#6
|
|||
|
|||
función CJVB_PRPS_POST Actualizar PRPS
Hola Foro, hola Vlozano,
en el proyecto me comentan que como la función es estandard y no es una función Z, el update podemos decir que es " correcto" y que por tanto puedo usar esa función ( aunque tenga el UPDATE TASK) dentro. |
Herramientas | Buscar en Tema |
Desplegado | |
|
|