ViteSoft - Compartilhando tecnologia

Ando percebendo que às vezes (aleatoriamente) o módulo clint para de responder. Seja jogando, usando o Word ou apenas o IE. Quando o cliente dá um clique na tela do VSC Clint “travado”, aí aparece àquela tela do Windows perguntando se deseja finalizar o programa. Se o cliente finaliza, na maioria das vezes ele faz isso, a máquina fica “inútil”, pois está com as restrições aplicadas.

Pensei que para resolver o problema, teria que apenas por um ícone do VSC Clint no desktop do Windows, só que quando da esse problema, os ícone do desktop no Windows desaparecem.

Sei que o fato do módulo administrador está travando, pode provocar isso, pois isso aconteceu comigo e eu resolvi o problema melhorando meu servidor. Também sei que outras coisas podem travar um processo, no caso o VSC Clint.

Quais seriam as possíveis causas para que o VSC Clint pare de responder?

Alguém tem alguma sugestão?

Pô galera, parece que só os moderadores podem responder os posts.!
Vamos lá arrisquem, é livre!!!

Bom, já que fomos chamados, cá estamos. :-)
Se for criado um core que controlará a interface com o usuário. Isto porque a parte da interface está sempre sujeita a erros, com o core rodando sempre o controle de tempo será mantido e a interface será chamada novamente. Mas isso ainda demora um pouco.

Minha humilde sugestão é:

Soube do sistema muito usado em supermercados, MultPDV. Esse sistema utiliza uma base de dados intermediária em cada estação, do tipo texto. Se o servidor cai, as estações continuam a funcionar com a base interna de cada estação. Quando o servidor volta a responder, a estação descarrega os dados guardados na sua base interna no servido e em seguida elimina o arquivo.

Isso garante o funcionamento do sistema, mesmo com o servidor não respondendo e divide a carga de processamento com o mesmo, quando ele estiver sobrecarregado e não tiver respondendo.

O que poderia ser utilizado, ao invés de arquivo texto comum, seria o uso de um XML. Com isso, desacoplaria os dois módulos, diminuindo o número de conexões simultâneas a base de dados e garantindo o funcionamento das estações, mesmo com o servidor sem responder.

Desculpe a minha pretensão na sugestão. Pode até ser burra, mais é de coração!

Primeiro venho reforçar que aceitamos e gostamos de todas as sugestões e opniões emitidas no forum. É para isso que serve o forum para todos poderem expor suas idéias, sugestões, opniões e trocarem idéias. É uma forma de todos interagirem e melhorarem o sistema que, insisto, é de vocês.

Quanto a base de dados local em cada estação existe um problema que é o seguinte: o que vocês vendem aos seus clientes é abstrato. Vocês vedem tempo, diferentemente de um mini-mercado, por exemplo. As informações que estão gravadas na base local dos pontos de venda de um estabelecimento deste tipo são basicamente duas: o preço dos produtos e a quantidade de cada produto que foi vendida naquele ponto. Quando o módulo cliente do sistema sobe em um ponto de venda ele lê do banco de dados os preços dos produtos, feito isso a conexão pode cair que tudo continua funcionando normalmente. Durante o funcionamento ele vai gravando localmente as vendas que passaram por esse ponto. Depois quando a conexão volta ele passa para o servidor as vendas e o servidor atualiza o estoque. E ele pode fazer isso por um motivo bem simples: ele não precisa controlar o estoque. Pois se tem alguém com uma lata de extrato de tomate passando no ponto de venda é porque a lata de extrato de tomate existe e pode ser vendida. O sistema tem a função de controlar o que foi vendido, margens de lucro, estoques, etc mas sem sistema as mercadorias continuarão sendo vendidas.
Já um sistema de lan house é um pouco diferente, o que ele vende é justamente a informação, a informação de quanto tempo aquele cliente pode utilizar uma estação. Então essa informação precisa ser verificada e anotada a cada utilização, o VSCyber atualiza essa informação a cada 2 minutos e temos usuários que acham muito tempo, gostariam de ver o tempo "correndo" a cada segundo. O que poderia acontecer se o sistema permitisse o acesso à uma estação sem conexão com o banco de dados? O cliente entraria em uma estação, retiraria o cabo de rede e utilizaria a estação, com isso a informação de utilização não ficaria gravada no banco de dados. Então as demais estações no estabelecimento ainda teriam a informação antiga de que aquele cliente tem saldo, com isso ele pode logar em outra estação e usar quanto tempo desejar. O funcionamento é mais parecido com os caixas eletrônicos que só permitem uma operação de saque caso a conexão com o servidor esteja estabelecida, pois caso contrário seria possível sacar o saldo de uma conta em mais de um caixa, porque faltaria aos outros caixas a informação do primeiro saque.
A boa notícia é que existe uma solução para o caso de perda de conexão: cartões smartcard. Nesta solução a informação do saldo do cliente fica gravada no cartão. A leitora verifica o saldo do cartão e atualiza a informação de utilização a cada ciclo de atualização. Isso também possibilita a utilização do saldo do cliente todas as lojas de uma rede, por exemplo, ou para os proprietários que tem mais de uma loja. No momento o investimendo das leitoras ainda é considerável, mas em breve ficará mais acessível. Já temos pessoal pesquisando esta tecnologia e logo o sistema terá suporte para funcionar com smartcard.

Caro André,

Sobre o funcionamento do supermercado, concordo plenamente com você. Já havia pensado nisso antes de postar. Minha idéia não é fazer da mesma forma que o supermercado, e sim apenas garantir que as informações contabilizadas (tempo utilizado, atalhos abertos...), não fossem necessários que o servidor estivesse respondendo todo tempo. Estou falando do não sincronismo com o módulo ADM.

Sei que as estações DEPOIS DE LOGADAS continuam funcionando. È sobre isso que eu estou falando. Se for possível que as estações continuem com os clientes logados, nesta circunstância, a estação poderá está assíncrona com o servidor, se o servido parar de responder momentaneamente, a estação não travariam pois elas passariam a gravar na base local provisoriamente, dentro do tempo limite.

Isso tudo, é claro, depois que o cliente estiver logado e também, dentro do tempo mínimo de "Minutos sem conexão" (que é = a 10).

Link relacionado: Comunicação Assíncrona e Síncrona

Acho que eu me expliquei melhor.

T+

É importante esclarecer que a comunicação com o módulo Administrador é totalmente dispensável, pois o módulo Client estabelece diretamente a comunicação com o SGBD Firebird. É através desta comunicação que o módulo Cliente realiza a validação da senha do cliente, do saldo do cliente e atualiza as informações de utilização. A conexão com o módulo Administrador serve apenas para executar as funcionalidades do menu Estações.

Outro ponto a ser observado é que mesmo sem conexão com o banco de dados o módulo client continua funcionando, sem travamentos, apenas ocorre uma lentidão ciclica durante as tentativas de reconexão.

Se na sua rede existem travamentos constantes o motivo deve ser outro. Recentemente criamos um roteiro para manutenção das estações. Se o seu servidor tem quedas constantes é altamente recomendável que as funções desta máquina sejam revistas e que se tente deixá-la, o máximo possível, dedicada ao sistema.

Entendo. Já sigo este roteiro.

Já que a comunicação entre o Clint e o ADM (indiretamente), normalmente é por intermédio do Firebird. O que pode está travando o VSC Clint?

Percebo que quando o VSC Clint está travando, é quando se manipula uma janela do IE. Quando alguém minimiza ou restaura aqualquer janela do IE, ai apenas o VSC Clint trava e depois de um tempo volta.

A opção de "Gerar Log do IE" está ativada? Experimente fazer a limpeza do log disponível no menu Ferramentas / Limpar Log do Internet Explorer.

Caro Eduardo,

Foi ótimo ter lembrado sobre isso, pois, em dois meses de uso, a base de dados estava dom 70Mb. Retirei o log do IE e limpei-o. Caiu para 14Mb.

A carga diminuiu muito, e as estações param de não responder.

Sobre isso, ta legal.

André,

Sobre a comunicação do Clint com o SGDB, isso esta claro.

Normalmente a maquina do modulo administrativo é a mesma maquina do banco. O problema é quando o servidor da base de dados passa a não responder e o Clint passa a não responder também. Poderia diminuir um pouco a "dependência da resposta" do servidor da base de dados para que a estação não travasse. Poderia utilizar Threads.

Não sei exatamente, e só uma sugestão.

Em fim. A idéia é que quando o servidor da base de dados trava, a estação não trave também.

T+