Formulário Registro Único não posiciona no novo registro após cópia [RESOLVIDO]

Olá meus amigos.

Estou com um formulário do tipo Registro Único (mestre-detalhe).

Criei um botão PHP que copia o registro atual (tabela mestre), gera um novo ID, copia os registros da tabela filha e grava normalmente no banco. A cópia está funcionando corretamente.

O problema é que, após a inserção, eu quero que o novo registro (copiado) apareça na tela, mas não acontece. Ele volta para o primeiro registro da tabela. O novo registro só aparece corretamente se eu sair da aplicação e entrar novamente.

Alguém já passou por isso ou sabe como fazer o formulário Registro Único posicionar automaticamente no novo registro após um INSERT via botão PHP?

Vou colocar o código abaixo para facilitar a análise.

sc_begin_trans();

//Captura ID origem
$id_origem = (int){ECF_NUMERO};

//Insere orçamento (SEM ECF_NUMERO - Auto Incremento)
$sql_mestre = "
INSERT INTO orcament
(CLI_CODIGO, MO, MATERIAL, DESC_ORC, MO_PERCENTUAL)
VALUES
({CLI_CODIGO}, {MO}, {MATERIAL}, ‘". str_replace(" (Cópia)", “”, {DESC_ORC}) ." (Cópia)’, {MO_PERCENTUAL})
";

sc_exec_sql($sql_mestre);

//Pega ID novo
sc_lookup(idnovo, “SELECT LAST_INSERT_ID()”);
$id_novo = {idnovo[0][0]};

//Copia itens
$sql_itens = "
INSERT INTO itorc
(ECF_NUMERO, PRO_CODIGO, PRO_QUANTIDADE, PRO_VENDA, IOR_TOTAL)
SELECT
$id_novo, PRO_CODIGO, PRO_QUANTIDADE, PRO_VENDA, IOR_TOTAL
FROM itorc
WHERE ECF_NUMERO = $id_origem
";

sc_exec_sql($sql_itens);

// Confirma na base de dados
sc_commit_trans();

OBS.: já tentei diversos codigos:


sc_commit_trans();
sc_redir(form_orcamento, ECF_NUMERO=$id_novo);


echo “”;
sc_exit();


Também tentei usar variável global:
[glo_novo_id] = $id_novo;

Tem que chamar o
Formulário mestre passando o novo id como parametro

Haroldo obrigado por sua dedicação em ajudar.

Mas já passei e nada acontece.

sc_commit_trans();
sc_redir(form_orcamento, ECF_NUMERO=$id_novo);

Verifique se o valor do id está chegando.
Coloque em modo
Debug

Haroldo, segue o debug:

(pdo-mysql): SELECT CODIGO, CLIENTE FROM clientes WHERE CODIGO = 1 ORDER BY CLIENTE LIMIT 0,10

Mesmo navegando em outros clientes, ele sempre mostra CODIGO = 1

Esse campo eu vou pegar os dados dos clientes em um lookup

(pdo-mysql): INSERT INTO orcament (CLI_CODIGO, MO, MATERIAL, DESC_ORC, MO_PERCENTUAL) VALUES (65 , 486.89 , 1081.98 , ‘TESTE SOMENTE TESTE (Cópia)’, 45.00 )
(pdo-mysql): SELECT LAST_INSERT_ID()
(pdo-mysql): INSERT INTO itorc (ECF_NUMERO, PRO_CODIGO, PRO_QUANTIDADE, PRO_VENDA, IOR_TOTAL) SELECT 821, PRO_CODIGO, PRO_QUANTIDADE, PRO_VENDA, IOR_TOTAL FROM itorc WHERE ECF_NUMERO = 792

Quando clico no botão para realizar a cópia

Para pegar último id tem que user last_insert_id

duas coisas… a primeira é que o ID inserido tem que ser do mestre, logo, tenha ctz que é ele que tá sendo usado.

Adote a macro sc_log_add() para ir monitorando os pontos importantes e nesse caso dps facilita o rastreio. Ex: sc_log_add(‘insert’, “Retorno ID Mestre: $id_novo”);

  1. sc_redir(form_orcamento, ECF_NUMERO=$id_novo);

troque a variavel/PK para caixa baixa, pois embora isso possa ser/estar correto, já vi que o SC as vezes se perde e sempre usa tudo em caixa baixa. Ex: sc_redir(form_orcamento, ecf_numero=$id_novo);

Acho que isso vai resolver

Senhores, agradeço a disposição em resposta ao meu questionamento.

Como já realizei diversos testes e ainda não consegui resolver o problema do ponteiro após a clonagem do registro, adotei uma solução paliativa (workaround técnico).
O comportamento observado é o seguinte: sempre que realizo a clonagem de um registro na tabela, após a inserção o ponteiro do formulário é automaticamente reposicionado para o primeiro registro do dataset, em vez de permanecer no registro recém-inserido.
Como medida temporária, alterei a ordenação da aplicação para ordem decrescente pelo campo identificador (ID). Dessa forma, sempre que um novo registro é inserido (clonado), ele passa a ocupar a primeira posição no dataset, sendo automaticamente exibido ao usuário o ultimo registro que esta na primeira posição devido a ordenação.
Essa solução permanecerá ativa até que seja identificado e corrigido o problema raiz relacionado ao reposicionamento do ponteiro após o insert. No momento, o comportamento está atendendo à necessidade operacional.