"
Apoiado por

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.

10 comentários a “Como sabotar tabelas”

  1. Rui Fonseca Dias Diz:

    Boas

    Na segunda opção, se o utilizador não tiver acesso à transacção SE16N poderá sempre usa a UASE16N.

    abraços

  2. admin Diz:

    Olá Rui, obrigado. No entanto já lá se fala na UASE16N como alternativa ;)

  3. Custodio Diz:

    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!

  4. Allan Oliveira Diz:

    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

  5. Nuno Godinho Diz:

    Olá Allan,
    Excelente ideia. Assim farei, obrigado.
    Abraço,
    Nuno

  6. Renato Oliveira Diz:

    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

  7. admin Diz:

    Oi Renato! Obrigado! Tu não és só seguidor, também contribuis ;) Abraço

  8. Bruno Esperança Diz:

    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.

  9. Allan Cristian Diz:

    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!

  10. Alan Jhonis Diz:

    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.

Deixe um comentário


Acerca do Abapinho
O Abapinho é suportado pelo WordPress
Artigos (RSS) e Comentários (RSS).