[Resolvido]Percorrer Registros do Formulário Principal e do Subformulário

Olá, caros colegas.

A pergunta é aparentemente simples:

Como percorrer registro por registro de um subformulário (todos os seus registros) durante a rotina de percorrer registro por registro do formulário principal?


Por precaução, vou esmiuçar todos os detalhes para evitar desperdício de tempo dos senhores em elaborar sugestões que, talvez, já se perceberiam inviáveis.

Em meu BD, eu tive que criar novos campos em uma tabela que são preenchidos com base em vários cálculos (envolvendo assinatura digital e outras complexidades).
Tudo já está funcionando perfeitamente para os registros lançados após a última versão do aplicativo (destaco que esse sucesso deve-se em parte à ajuda obtida neste fórum; Obrigado!).
Agora, eu preciso "preencher" esses novos campos nos registros antigos (retroativo a Setembro de 2018) e, para isso, criei uma rotina que, para incluir os dados automatizados, basta que eu percorra registro por registro (dando foco em um campo específico desse subformulário).

No entanto, o BD (com dezenas de tabelas) é gerenciado por 9 formulários e, dentro deles, por um ou dois subformulários (sendo o subform existente em todos os 9 exatamente aquele que traz a tabela que eu preciso atualizar).

Não adianta eu abrir apenas esse subformulário (ou criar um novo formulário com base na tabela em questão), pois os dados a serem incluídos nos registros anteriores dependem dos dados tanto dessa tabela como das outras 9 tabelas ligadas aos 9 formulários principais. E não é só isso (aqui está o maior complicador)! Um dos dados refere-se tão-somente à posição do registro do subformulário com referência ao formulário principal a que está atrelado ("nº sequencial do registro" ou "página do subform"). Este último dado foi necessário para viabilizar a assinatura digital e é exatamente ele que impede que eu use apenas a tabela principal para a atualização.

Exemplo hipotético:

Form Principal: Cliente (1000 registros)
Subformulário: Compra (entre nenhum item e dezenas de itens, sendo cada item = 1 registro)
O bendito campo no SubForm!Compra = [pag]

1. Item 1 => [pag] = "AA"
   
2. Item 2 => [pag] = "AB"
   
3. Item 3 => [pag] = "AC"
   
4. Item 4 => [pag] = "AD"
   

Como eu não posso mudar a ordem dos itens, acredito que só me sobra a opção de percorrer registro por registro:

1. Cliente 1: item 1
   
2. Cliente 2: sem nenhum item
   
3. Cliente 3: item 1
   
4. Cliente 3: item 2
   
5. Cliente 3: item 3
   
6. Cliente 4: item 1
   

Para fazer a varredura, registro a registro, acredito que a melhor opção seja, basicamente, usar o  comando:

DoCmd.GoToRecord , , acNext


Mas eu não estou conseguindo fazer a "varredura" no subformulário. Aliás, eu consigo fazer apenas a varredura completa no subformulário ligado ao 1º registro  do formulário principal.
A partir do segundo registro percorrido (do form principal), ele foca apenas no "registro 1" do subformulário (ignorando eventuais outros registros).
Tentei de tudo que eu pude imaginar (mudando o foco várias vezes do principal para o subform e vice-versa), mas sem sucesso.

O subformulário tem a seguinte informação em um controle calculado (informação não incluída no BD): [nº_pág] e [total_páginas] (página = nº sequencial do registro do subform)
Incluí no Formulário principal o mesmo controle (com referência expressa ao subformulário).
Portanto, ao percorrer (manualmente) o formulário principal, em seu corpo já consta, em destaque, o dado do subformulário. Ex.: [5] = 5 páginas (registros/itens).
Esse dado (nº de itens do subform) seria a solução perfeita, mas por se tratar de um campo calculado, eu não soube como fazer o "automatismo da varredura" dar um tempinho para que tal campo "calcule". Até criei uma função "pausa", mas também falhou.

Após eu encher o meu código de msgboxes e abusar do Me.Refresh, eu descobri que, exceto quanto ao registro em que a varredura se inciou (cuja tela estava aberta; portanto, com foco nele e com todos os campos calculados em ordem), nos registros seguintes o código VBA acusa sempre "zero" como o valor de [total_páginas]. Por que isso?

Tentei usar os comandos abaixo, mas também não obtive êxito ("o objeto não aceita essa propriedade ou método"):


Dim pag As Integer
Dim Total As Integer

pag = Me![F-Em].RecordsetClone.AbsolutePosition + 1
Total = Me![F-Em].RecordsetClone.RecordCount

Como não consigo identificar o número de "itens" (registros) do subformulário relativo ao registro do formulário principal quando da varredura, não tenho como criar os laços necessários para sejam percorridos os registros (excedentes a um) do subformulário.

O código que eu inicialmente acreditava que funcionária é o seguinte:


Início:
   Me!numpages.SetFocus
   num = Me.numpages.value                 'Aqui está o problema: se maior que 1, só recebe o valor "zero", apesar de o controle [numpages] mostrar sempre o valor correto
   Me.Refresh
   Me![F-Em].SetFocus
   Me![F-Em]!Comando262.SetFocus

   If num = 0 ou num = 1 Then               'existindo um único registro ou nenhum no SubForm, passa para o próximo registro do Form principal
       Me!CmdoNF.SetFocus
       Me!numpages.SetFocus
       Me.Refresh
       DoCmd.GoToRecord , , acNext
   Else                                                  'existindo mais de 2 registros no SubForm, deveria varrer os registros do SubForm
       For pag = 1 To (num - 1)
           Me![F-Em].SetFocus
           Me![F-Em]!Comando262.SetFocus
           DoCmd.GoToRecord , , acNext
           Me![F-Em].SetFocus
           Me![F-Em]!Comando262.SetFocus
       Next pag
   End If

   If Not tt = TotalRegistrosFormPrincipal Then
       Exit Sub
   Else
       Goto Início
   End If

End Sub


Qualquer ajuda será bem-vinda.

Obrigado pela atenção de todos.
EA

Boa tarde,
O que você precisa é uma rotina em SQL para atualizar e não o formulário em si.

Poste aqui os campos (o nome exato) da tabela (com nome exato) que precisam ser atualizados
e a maneira como obtém a informação a ser inserida na tabela. Que tentamos algo.

Olá, Marcelo.

Creio que a solução em SQL não seja viável (sem me atrever a dizer "impossível"), pois alguns dos valores (exemplo principal: a bendita [página]) não são calculados com base em registros armazenados numa tabela, mas em situações que dependem exclusivamente de seu posicionamento (sequência) no Formulário-Pai. Há ainda o controle [DV] que chama uma função para calcular o dígito verificar pelo código Luhn e outros ligados a funções diversas. Como tudo isso se resolve facilmente pelo simples ato de focar o registro, talvez a via pelo SQL exija a criação de muitas linhas de código que inviabilizem a opção.

Exemplificando novamente uma das situações num BD hipotético:

Formulário Principal: "Cliente 25"
Subformulário atrelado a este "Cliente 25": 10 compras (10 itens = 10 registros = 10 páginas)
Controle calculado no Subformulário: [pág]

Compra 1 => [pág] = "AA"
Compra 2 => [pág] = "AB"
Compra 3 => [pág] = "AC"
Compra 4 => [pág] = "AD"
Compra 5 => [pág] = "AE"

Esse dado [pág] é essencial para, juntamente com valores e cálculos de outros campos e controles, formar a string a a ser assinada digitalmente.
Os registros anteriores estão desatualizados (sem a string a ser assinada) pelo simples fato de, na época em que os dados foram lançados, tal rotina ainda não existia.
Portanto, eu preciso "revisistar" todos os registros antigos para que esse cálculo seja efetuado automaticamente e possibilite a formação da string (esta, sim, será armazenada no BD).

Para que essa atualização ocorra, o sistema exige apenas que seja dado foco num determinado controle do subformulário (Me!SubForm!ControlePág).
Observação importantíssima: o foco deve ser dado no conjunto "Form-pai/SubForm-filho", pois o foco no subformulário isolado afetaria os valores dos controles calculados, gerando dados incorretos ou impossibilitando o seu cálculo.

A única questão que não consegui solucionar pelo vba foi a de, a cada registro visitado no formulário principal, "entrar no subformulário e visitar os demais registros desse sub".
Eu só consegui varrer o formulário principal e focar a "página" inicial do subformulário. Portanto, todos os registros do Subform que estão "por baixo" ("página 2" em diante de cada registro do Form-pai) estão desatualizadas.

Eu até consigo passar manualmente todos os registros (e, talvez, faça isso ainda hoje), com o uso de PageUp e do Mouse, solucionando essa questão após umas duas ou três horas de movimentos repetitivos.
Mas mesmo que eu assim resolva agir (acabando de vez com o problema), não ficarei satisfeito, por não ter encontrado uma solução pelo vba.

Portanto, não se trata necessariamente de "resolver a questão prática", mas também de solucionar esse "desafio teórico".

Obrigado, Marcelo, pela atenção e pela sua célere resposta.
EA

Sim, entendi. Mas em SQL sim, reduziria e muito a quantidade de códigos. Funções podem ser passadas direto na escrita da SQL, e cálculos
feitos em formulários podem serem feitos na sql (afinal, apenas o Access permite cálculos em formulários)... Ou seja, um loop e uma ou duas linhas em SQL já poderiam resolver todo o seu problema.

Sobre posição do registro no formulário, na verdade a posição do registro depende da ordenação origem dos registros e não do formulário.

Tenha em mente que os formulários são sim parte importante de seu sistema, mas a função deles e exibir informações. O processamento dessas
informação devem serem feitas em linhas de código, seja VBA (ou qualquer outro) ou SQL.

Enfim, da maneira que você está propondo, até deve ser possível, porém não o mais usual e prático.

Enfim, minha proposta é fazer como já mencionei. Mas o tópico está livre para que qualquer outro usuário possa te ajudar da forma que você
esta propondo.

Concordo com tudo que explanou, Marcelo.
No entanto, parece-me que isso não representa a minha situação.
Quase todos esses "controles calculados" a que em referi são processados pelo vba (mediante funções públicas e privadas; exceto nos casos mais simples, como incluir na string os dois dígitos do ano obtidos diretamente do campo [data completa])
No entanto, a "atualização" do BD a que me referi não significa pegar um dado antigo (exemplo data) e fazer um cálculo sobre ela (aí, sim, a sua explicação está perfeita).
No meu caso, a atualização significa inserir dados novos em campos novos (que, nos registros antigos, ainda estão com valor Null).
Felizmente, para que essa inclusão de dados ocorra, basta eu dar o foco em cada registro individualmente, o que torna bem simples a tarefa.

Vc disse que "a posição do registro depende da ordenação origem dos registros e não do formulário". Sim, perfeito. Mas, no caso de tabela utilizada em subformulário, os dados não seguem a mesma ordem da tabela principal (que está atrelada ao Form-pai), pois o Cliente 1 (cadastro mais antigo do Form-pai) poderá ter o "fechamento" de sua conta realizado após os Clientes 2 e 3, fazendo com que os itens de sua compra estejam com numeração posterior ou até intercalada com esses clientes mais novos.
Além disso, são vários controles ("caixas de texto") com valores calculados automaticamente pelo vba, utilizando dados da tabela atrelada ao Subformulário e às 9 tabelas atreladas ao formulários principais. Portanto, não creio que "um loop e uma ou duas linhas em SQL" sejam suficientes para resolver o problema.

Eu sei que "os formulários são parte importante de seu sistema" e que a "função deles é exibir informações". Tanto que praticamente tudo está sendo processado pelas "incontáveis linhas" do vba.
Reconheço que estou ainda engatinhando no quesito vba, mas estou procurando melhorar a cada dia; e, exatamente por isso, cá estou...

De qualquer forma, gostaria de saber como eu poderia agir de acordo com a sua proposta e estou aberto a ela (pois será útil de qualquer maneira, já que aprenderei algo novo).

Mais uma vez, obrigado pela ajuda.
EA

Eduardo Augusto escreveu:Reconheço que estou ainda engatinhando no quesito vba, mas estou procurando melhorar a cada dia; e, exatamente por isso, cá estou...

Então, se está engatinhando, ótimo oportunidade de "fazer do jeito certo". Se você receber qualquer instrução, de qualquer programador mais experiente,
eles apontaram uma solução semelhante a minha. Mas você está convicto de que a forma que você quer é a melhor para o seu caso. Tudo bem, você quem determina o andar da carruagem no que diz respeito ao seu sistema.

Enfim, eu apontei a solução mais viável (o que na sua concepção não é) e para isso pedi apenas os nomes dos campo e tabelas envolvidas para eu tentar te ajudar, mas resolutamente você insiste que apenas do seu jeito da certo...

Ok, como falei, o tópico está livre para qualquer um tentar fazer do jeito que você quer e espero de verdade que alguém consiga ou você mesmo chegue a
solução pretendida.

Sucesso.

Prezado Marcelo:

Desculpe-me se dei a entender que estou convicto de que a forma que eu apontei esteja certa.
Não é isso. Aliás, longe disso.
E, como já disse, é exatamente por isso que estou aqui, em busca de ensinamentos com os mais experientes (rol em que obviamente vc está incluído).
Também não estou sendo relutante com você. Apenas expus meu ponto-de-vista para que vc e os demais participantes possam identificar em que ponto estou me equivocando, colaborando para o meu aprendizado.

Enfim, eu aceito sua sugestão.

Mas de quais dados vc exatamente precisa?
São dezenas de campos calculados para formar duas longas strings, sendo alguns "cálculos" simples (extração dos 2 dígitos do ano, inversão da string data concatenada com a hora, inserção de um novo código conforme a especialidade, etc) e outros complexos (extração das iniciais do nome, cálculo do DV pelo método Luhn, assinatura digital da string, código alfabético de 2 caracteres identificador da sequência dos itens em cada bloco, etc).

Sendo assim, para não lhe sobrecarregar com tanto material, se vc puder me ajudar indicando a solução em SQL apenas para este caso mais pontual (que julgo ser o mais complexo), talvez eu consiga adaptar todo o restante conforme sua orientação.

Eis o caso:
Incluir, em todos os registros de 2018 da tabela "secundária" [itens], num campo recém-criado denominado [pag], o valor referente ao posicionamento exato do referido registro  no "conjunto de registros" atrelados, por exemplo, ao registro "João" da tabela "principal" [Clientes].

Mais uma vez, obrigado pela sua gentil atenção e perdoe-me por eventual mal-entendido.
EA

Vamos lá... Conversando nos entendemos!

O posicionamento como vc obtém? É a chave primária, ou a ordem do registro?
Pergunto isso porque um recordset (conjunto de registros) tem uma propriedade chamado absolutposition. Mas no geral, um subformulário é ligado a uma chave
primária.

Em tempo, precisamos dos nome das tabelas (uma é itens?) e o nome dos campos envolvidos e como estão os relacionamentos entre elas.

Você não consegue disponibilizar o sistema somente com estes dados (uma parte dos dados) e também não precisa de todas as colunas.

Tabela
frm principal
sub frm

Eis o caso:
Incluir, em todos os registros de 2018 da tabela "secundária" [itens], num campo recém-criado denominado [pag], o valor referente ao posicionamento exato do referido registro no "conjunto de registros" atrelados, por exemplo, ao registro "João" da tabela "principal" [Clientes].

Prezados Marcelo e Scandinavo:

Eu vou preparar o material amanhã.
Assim que ficar pronto, eu farei contato.

Muito obrigado pelo apoio.
EA