Problema com botões de navegação

Formulários
#1

Em um formulário, minha chave é o ‘ID’, que é atribuida pelo proprio usuário.

Isso pq é um cadastro de clientes que já vem de outro sistema, e queria manter o mesmo ID do cadastro anterior.
Só que alguns clientes não vou transferir para esse novo sistema.

Então, o cadastro hoje está assim:

ID / Cliente
002 / Cliente TAL
003 / Cliente Fulano
005 / Cliente Ciclano
007 / Cliente Beltrano
e assim por diante

Só que os botões de navegação estão se perdendo!

Entro no registro do Cliente 005.
Clico no botão ‘Histórico’ que direciona para uma consulta com dados desse cliente. Tudo ok.
Clico em retornar, ele volta pro cadastro do Cliente 005. Tudo ok.
Mas os botões ‘primeiro’ e ‘anterior’ voltam desabilitados como se o 005 fosse o primeiro registro da tabela. Quando não é, pois tenho o 002 e 003.
Se eu clico no botão ‘próximo’ ao invés de ele passar do 005 para o 007, ele vai pro 002.

O que será que acontece?

#2

Jaqueline bom dia,

Isso acontece comigo desde a versão 4. Por conta disto, eu desisti de usar os botões de navegação nos forms, forçando o usuário a voltar para a grid e escolher o próximo registro. Parece que o problema é que, no retorno de uma outra consulta, o controle do form se perde, colocando o registro editado como o primeiro.

#3

Jaq,

Nunca passei por esse problema… sequer tinha observado e, a partir de agora vou ficar atento, porque isso é relativamente sério…

Só pra constar… você tem algum ORDER BY ou índice associado a este form/tabela?
Se não tem… já tentou criar pra ver se o problema persiste?

Mande notícia.

[]

#4

Kleyber, nunca tinha visto isso, na verdade nunca tive nada parecido. Mas é algo preocupante… pois os botões de navegação são pra facilitar nossa vida. Minha ‘estrutura’ é essa:

Consulta de Clientes
Cadastro de Clientes
Consulta Histórico do Cliente

Se estou no histórico do Cliente 005 e quero ver o do cliente 007, tenho que voltar até a Consulta de Clientes. Pq afinal meu exemplo acima tem só 4 registros, Mas minha tabela está com muito mais!

Jovito.
não tenho nada de especial nessa tabela. É um formulário criado pelo SC com base na tabela onde só arrumei o cabeçalho e nome dos campos… mais nada!

Vou fazer mais alguns testes e posto aqui qq novidade.

Alguém da Netmake poderia se manifestar sobre isso? Será que pode ser algum erro meu?

#5

Coloque a app em modo debug, execute, e nos informe como esta o select da consulta retornada.

#6

Da aplicação CLIENTES (FORMULARIO UN.REGISTRO):
(mysql): SELECT clicodigo, clicnpj, cliie, cliim, clistatus, clirazao, clifantasia, cliendereco, clinumero, clicomplemento, clibairro, cidnome, clicep, cliestado, clifone1, clifone2, cliemail1, cliemail2, from tab_clientes order by clicodigo LIMIT 0,1

Da Aplicação HISTÓRICO (CONSULTA):
(mysql): SELECT histstatus, hisdataini, hisdatafin, hisreferente, clicodigo, hiscodigo from tab_historicos where clicodigo = 7 order by hisdataini asc LIMIT 0,12

Na Consulta de Históricos, eu não exibo os campos clicodigo e hiscodigo.

*** Atualizando:
Nossa… agora vendo aki, percebi que logo que entro no registro do ‘meio’ os botões de navegação anteriores já ficam ‘desabilitados’.
Se pela consulta de clientes entro no 005, ele não habilita os botões caso eu queira ir pro primeiro (002) ou anterior (003).

#7

Pessoas…
Acho que o problema é ‘mais embaixo’ mesmo.

Porque entrei em outra aplicação ‘Titulos a Receber’ onde a chave é tipo varchar, e acontece a mesma coisa.
Tenho 6 Titulos cadastrados:
1/1-12
1/2-12
1/3-12
1/4-12
1/5-12
1/6-12
Se pela consulta entro em modo de edição do título código 1/4-12, os botões de navegação Primeiro e Anterior Estão desativados.

#8

Jaq,

É bom lembrar que a V6 dispõe do QuickSearch nos forms… vc já tentou consultar por ele?

[]

#9

Jaq.

O Sc faz um count(*) no select, se tiver uma clausula where e o count resultar em apenas um registro, a navegação é desabilitada mesmo, se ao entrar na app já tiver um where que retorne um registro único, não haverá como habilitar esses botões.

#10

Jovito,
já pensei em colocar esse recurso no formulário (pois eu não deixava na barra de ferramentas). Mas acho que se realmente o SC tá dando esse ‘erro’, é complicado né poder colocar os botões mas eles virem com ‘falha’?!

Haroldo,
Eu vi esse select count que os formulários e consultas estão fazendo em modo debug, todos estãos sem clausula Where:
(mysql): select count(*) from tb_clientes

Se alguem puder depois fazer um teste rápido, é só criar uma tabela com uma chave tipo varchar e gerar um formulário unico registro e uma consulta com ligação para esse formulário.
Se realmente for um problema que vem ocorrendo, a Netmake poderia colocar na lista de ‘itens a serem vistos’.

Obrigada pela atenção Jovito e Haroldo!

#11

Jaq,

Tou muito preocupado com isso… ontem a noite fazendo uns testes em uma app, encontrei um problema muuuuiiitttooo parecido com o seu… no meu caso foi muito pior, porque o registro deveria ser alterado… e o SC estava trazendo da grid para o form o último registro do select, ao invés do selecionado (lá qualquer)… como era teste, e em testes a gente fica colocando coisas doidas, e essas coisas doidas são sempre iguais, só fui descobrir que o problema estava existindo por conta desse seu tópico…

Esquentei a cabeça por longas horas, não descobri nem resolvi o problema… hoje vou me debruçar sobre ele… aaaffffff…assim que tiver alguma novidade volto a postar.

[]

#12

Foi o que eu falei no início do tópico… a solução foi não usar os botões de navegação no form. É chato, mas por enquanto foi o que resolveu pra mim.

#13

Jovito / Haroldo / Kleyber

Eu tive um problema na versão 4 com os botões de navegação em um Formulário que tinha um campo do tipo 'documento(nome do arquivo).
Se eu estava editando os dados do registro 020 e nesse campo (documento) tinha por exemplo já inserido o ‘documento001.pdf’.
Se eu usava os botões de navegação, e fosse pra outro registro alterar digamos o nome desse registro, ele puxava o ‘documento001.pdf’ pra esse registro. Mesmo eu não tendo mexido nesse campo e mesmo que ele estivesse já com outro documento.

Foi complicado.
Tive que desabilitar acho que o ‘processamento ajax’ do formulário ou tirar os botões de navegação tb.

Não testei isso depois nem na versão 5 nem na 6.

Agora o ‘probleminha’ desse tópico já tá me enxendo!

#14

nas versões 5 e 6 o ajax é obrigatório, não tem mais como desabilitar.

Já tentou colocar a cláusula order by no select principal?

#15

coloquei um ORDER para o campo ‘clicodigo’.
Não adiantou… deu na mesma!

#16

e para outro campo da tabela?

#17

mesma coisa…

#18

Nós estamos com o mesmo problema. Já alertamos a NetMake sobre isso desde a versão 5, a 1 ano atrás.
Se você tem uma tabela com 1000 registros e filtra 500 e passa para o formulário este filtro, a navagação fica entre os quinhentos. Tudo legal, mas, se vc selecionar qualquer registro da consulta, o formulário apresenta este registro mas quando você navega ele se perde, volta pra o primeiro registro dos 500.