Como sabotar tabelas
Mais um artigo em auxílio dos que buscam a subversão subreptícia. Espiões, reparem como editar uma tabela que não pode (e provavelmente não deve) ser editada. Apresento-vos 3 técnicas. A primeira já caducou há anos, a segunda está em vias de caducar e a terceira vamos ver quando caducará.
1. SE16 /H OK_CODE EDIT
O primeiro sistema é já do século XX e usar a velha transacção SE16.
- na transacção SE16 escolhe a tabela a editar
- selecciona os dados e vai para o detalhe de um dos registos
- /H para debug
- muda o valor da variável OK_CODE para “EDIT”
- F8 para continuar
Se tudo tiver corrido bem agora o registo está editável. Depois é só gravar.
2. SE16N &sap_edit
- na transacção SE16N escolhe a tabela a editar
- selecciona os dados se quiseres filtrar registos
- no campo da transacção escreve &sap_edit e enter
- F8 para ires para a lista de dados
Um Service Pack recente da SAP inibe esta técnica. Se, com um bocado de sorte, o teu sistema estiver desactualizado, agora o registo está editável. Depois é só gravar. Se não der, experimenta a mesma coisa mas com a transacção UASE16N ao invés.
3. Função SE16N_INTERFACE
- transacção SE37, função SE16N_INTERFACE
- F8 para testar
- parâmetros:
- I_TAB = KNA1 :-)
- I_EDIT = X
- I_SAPEDIT = X
- IT_SELFIELDS preenchido opcionalmente para restringir os registos a editar
- novamente F8 para executar
Se tudo tiver corrido bem agora aparece uma lista de registos editável. Depois é só gravar.
Vá, agora não comeces para aí a sabotar tabelas como se não houvesse amanhã!
Obrigado a Renato Oliveira pelo material secreto.
O Abapinho saúda-vos.
12 de março de 2012 às 17:25
Boas
Na segunda opção, se o utilizador não tiver acesso à transacção SE16N poderá sempre usa a UASE16N.
abraços
12 de março de 2012 às 17:33
Olá Rui, obrigado. No entanto já lá se fala na UASE16N como alternativa ;)
21 de março de 2012 às 22:50
Meu metodo preferido eh o debug na SE16. Porem apareceu na nova SCN um possivel transtorno ao utilizar essa “tecnica”:
http://scn.sap.com/thread/1595246
Portanto, muito cuidado!
3 de abril de 2012 às 17:01
Nuno,
Você poderia criar um post falando sobre a tabela USR02 e sobre como é possivel utilizar uma senha anterior. Apagando os campos OCOD1, OCOD2, OCOD3, OCOD4 e OCOD5, é possivel coloca-las novamente!
=)
Creio que muita gente tem raiva de não poder colocar umas das 5 ultimas senhas. Isso é muito irritante.
Abraço
Allan Oliveira
3 de abril de 2012 às 20:01
Olá Allan,
Excelente ideia. Assim farei, obrigado.
Abraço,
Nuno
5 de abril de 2012 às 12:20
Olá Nuno,
É com grande satisfação que acompanho o abapinho.
Sempre com excelentes dicas.
Saudades das nossas tertúlias de abap (e outras) quando estivemos a trabalhar na ICA.
Até ao próximo projeto.
Grande abraço,
Renato Oliveira
5 de abril de 2012 às 12:29
Oi Renato! Obrigado! Tu não és só seguidor, também contribuis ;) Abraço
16 de maio de 2012 às 10:03
Boas!
Outra manha interessante (que me vi obrigado a utilizar aqui no cliente onde estou) é na SE16N, fazer /H para entrar em debug, e mudar na estrutura GD os campos EDIT e SAP_EDIT para ‘X’. Não sei porquê mas o &sap_edit não funcionava e eu tenho pavor da SE16, então vi-me forçado a descobrir este método.
Cumps, e obrigado pelo blog.
29 de maio de 2012 às 13:50
Bom dia!
Apenas a título de informação, existem clientes que bloqueiam o acesso à “SE37” e “SE16N”/”N”, porém, geralmente, não limitam a SE38…
Uma solução rápida, seria executar o programa RK_SE16N que é o mesmo que a transação “SE16N”…
Abraços!
9 de setembro de 2015 às 15:53
Bom dia Nuno,
Muito legal seu portal, sempre ajuda muito.
Só uma informação. No meu caso entrei na linha “if code = ‘SHOW’.” e alterei para “EDIT” e o campo foi desbloqueado para modificação.