[RESOLVIDO] - Tela controle SC v8

Bugs
#1

Bom dia ae galera.

É o seguinte, estou usando a tela de controle para fazer processamentos no banco de dados. Foi a tela que encontrei onde posso fazer isso. se tiver errado me avisem.

É uma tela que serve para manutenção de produtos mudando o produto do GRUPO ATUAL para um GRUPO NOVO.

nela so tem esses 2 campos GRUPO ATUAL e GRUPO NOVO.

O que notei como BUG é a ligação do tipo CAPTURA.
Quando vc cria a ligação do tipo CAPTURA, o campo não permite mais digitação, nem aparece o botão da CAPTURA.Aparecendo só o Label. Pensei que estava fazendo algo errado, mais fiz a mesma coisa na tela de FORMULÁRIO e FUNCIONOU.

no aguardo.

#2

Olá Renato,

Sim, o controle é utilizado no processamento das regras de negocio do sistema.

Nas propriedades da ligação do botão de captura tem opções para impedir a alteração do campo. Dá uma olhada lá.

Att,

Tulio

#3

Vlw Tulio!!!

Era isso mesmo os checks estavam desmarcados.
obrigado!!!

#4

Pessoal,

Em app do tipo controle, onde podemos adicionar processos diversos, encontrei algo que para mim é novo, e gostaria de saber o que preciso resolver, se: nas configurações do apache, php ou do PostgreSQL.

Trata-se da necessidade de processar vários registros através de leitura por SELECT, selecionando o que vai ser atualizado e na sequência fazer o while () para efetuar diversos cálculos e atualizar os registros retornado no SELECT inicial.

A impressão é velocidade para processar, mas o que investigar ?

O uso de UPDATE num único comando com uso de WHERE é super rápido (utilizei o psql), mas há situações que têm que se tratar a informação para depois salvar, registro a registro.

Att,

Jocimar

#5

Porque não usa uma Stored Procedured.

#6

Se entendi direito dever ser a quantidade de registros retornados que está atrapalhando a performance,

Se puder usar um limitador de resultado como o FIRST ( ou LIMIT no mysql)

Eu acho que não tem nada a ver com PHP ou Apache é algo no SQL

Att

Flávio

#7

Vou estudar, mas a princípio tudo têm que ficar na app!

Att,

Jocimar

#8

Flávio,

Desculpe se não entendi, mas pela dica teria que ter 2 while, um para controlar a quantidade de registro dos SELECT e outro aninhado para processar aqueles selecionados, e assim fazer até não obter mais resultado do SELECT

Vou testar!

Att,

Jocimar

#9

Se a solução exige o processamento de todos os registros do SELECT então não adiantará quebrar em várias partes

Uma PROCEDURE evitaria o trafego de dados entre a aplicação e o banco , fora isso não ha muito o que fazer senão deixar o BANCO fazer o UPDATE calculado
" UPDATE TABELA SET A=A*35+(SELECT … ) WHERE ( CLAUSULA WHERE DO SELECT ) ";
ou as dicas básicas
não utilizar SELECT * a não ser que vá utilizar todos os campos
fazer o UPDATE utilizando o ROW ID (no ORACLE E POSTGREE sei que funciona)

Espero ter ajudado

Flávio

#10

Flávio,

Com certeza ajudou, agora só depende de ver o que atenderá.
Em minha necessidade, tudo deve ficar na app, o BD somente “guardar”.

Tenho vários UPDATE da forma como mencionou, e é uma “bala”, só que existem “cálculos” que depende de variáveis e condições que é necessário “tratar”.

Venho “construindo” o sistema com processos individuais, já no momento que o usuário vai fazendo a manutenção dos dados (insert / update), tentando eliminar “processos em lote”, pois sabia que o uso de SGBD fazendo tudo na app teria este “problema”.

Neste “processo em lote”, na app de controle criei opções para o usuário selecionar o que deseja processar, e independe da seleção é de 70 a 80 registros / segundo, que na situação tratada não é problema, pois poderá levar de 2, 3 segundos até 30 segundos no máximo.

O uso de SGBD é excelente, mas dá saudade da velocidade e facilidade do harbour em linux com as tabelas nativas (um avião).

Att,

Jocimar