Sistema rodando em rede, qual a melhor alternativa?

[will_pacini]

Boa tarde a todos, trabalho em uma empresa que desenvolve sistemas de controle de caixa, venda, estoque e afins para uso comercial, principalmente drogarias, estamos a quase 20 anos no ramo, e a experiência é grande, não sou o programador, faço a parte técnica e algumas manutenções ou alterações no banco de dados .dbf pelo dbase...

Estou a 5 anos trabalhando aqui, e venho da época onde a maioria de nossos clientes possuíam o win98, no win98 podíamos trabalhar com uma rede tranquilamente que era bem difícil dar algum tipo de erro, quando começamos a instalar o sistema em winXP, a coisa começou a ficar diferente, não sei se é algo que não estamos prestando atenção ou é a forma que o sistema foi construído,

Hoje estamos utilizando o 5.2 + Rtlink, e quando falamos de rede, nós instalamos apenas 1 exe no micro servidor junto com o banco de dados, e compartilhamos essa pasta pela rede, assim em um micro terminal, apenas puxamos esses exe do servidor por um ícone ou por um .bat e o .exe é executado, más o programa fica dando erro, a cada exe aberto, é criado um arquivo de movimento adicional no banco de dados, chamado de mov, se tiver 7 micros da rede, terá o mov1, mov2.... e por ai vai...

Isso funcionava normalmente em ambiente win98, más no XP, e 7 o erro já virou rotina, então a dúvida é, como é feito a maioria dos sistemas para funcionar em rede? É pelo nosso método, ou cada micro na rede teria que ter um .exe próprio e esse .exe fazer a busca pelo caminho de rede p/ achar o banco de dados?

Obrigado.

[rochinha]

Amiguinho,

Houve épocas que para executar um aplicativo em rede eu apenas atribuía como Read-Only e o mesmo abria em quantas maquinas quizesse. Não sei se alguém da velha guarda lembra disto.

Como voce disse o aplicativo esta instalado em uma maquina e as outras que o acessar executam por link mapeado o abertura direta?

O melhor é mapear uma letra como padrão em todas as máquinas de forma que algum comando de escrita no sistema possa gerar arquivos de controle somente neste local. A não ser que o aplicativo leve em consideração informações do terminal como numero de série do hd para abrir movimentos para cada caixa adicional.

Compartilhe a pasta e em cada terminal mapeie para uma unica letra, exemplo T:

[will_pacini]

Rochinha, você está me dizendo então que o ideal seria 1 .exe para cada micro?

Hoje trabalhamos como você disse, 1 .exe no servidor, e os terminais apenas mapeiam a pasta e puxa um ícone no desktop, ex: w:\pasta\exe.exe

Na verdade no terminal não tem nada do sistema, tudo está no servidor, uma e acredito que única vantagem de trabalharmos assim é o caminho da rede, ele sempre poderá mudar, mudar nome de micro na rede, que sempre funcionará, apenas mudamos a letra da unidade mapeada...

Já com 1 .exe em cada micro, o caminho de rede terá que ser específico e fixo, caso contrário o executável não achará o banco de dados, certo?

Obrigado.

[Pablo César]

Olha analisando os pros e contras, eu acho que alterar o sistema a esta altura no convém. Na minha opinião, o melhor seria que cada máquina tivesse o seu executável, seria uma coisa a menos para trafegar em rede e apenas as instruções de acesso ao banco de dados trafegariam. Mas se o seu sistema está rodando a muito tempo assim, o que tem que atacar no momento é os erros que ocorrem. Isso não dá pra deixar de lado. Você não mencionou que tipo de erros vem dando.

Quanto a padronização sobre a unidade a ser acessada que o colega Rochinha mencionou é bom manter. Mas tudo depende do seu sistema. Como são aberto os dados, se menciona o path com a unidade (drive do mapeamento) ou não. Se bem que eu tenho um sistema que trabalha com um único EXE (no servidor) e as unidades são mapeadas preferencialmente na mesma unidade padrão, mas também tem terminais com unidades diferentes e não dão problemas.

O que eu tenho percebido é os arquivos de índices CDX, dizem que mostram-se mais seguros e mais rápidos, principalmente em rede. Ter uma boa rotina de manutenção é fundamental para re-construção de índices NTXs como creio que deve ser neste seu caso.

Outro conselho é evitar o WINXP SP3, aqui foram relatados alguns bugs. Eu prefiro o SP2. Também seria bom verificar a configuração de ambiente de cada estação. Aqui no fórum na seção de Downloads tem um aplicativo que corrige vários itens relevantes a acesso a DBFs, chama-se Set_XP.exe e pode ser executado em cada estação sem problemas. Pode baixá-lo clicando aqui.

Demais, seria conveniente você colher todos os erros que ocorrem e ir postando para a gente ter uma ideia do que está acontecendo. Mas vou adiantando que sem fontes, fica muito difícil de prognosticar algo certeiro.

[rochinha]

Amiguinho,

Rochinha, você está me dizendo então que o ideal seria 1 .exe para cada micro?

Não quis dar esta idéia, mas ela seria válida para desafogar o processador já que você usa um linker antigo e que não tem muitos recursos de uso aprimorado de memória como Blinker ou EXOspace, fazendo com que o processador do servidor fique escravizado.

Colocar o executável em cada máquina poderá ser uma saída válida se, e somente se, o aplicativo tenha direcionamento para os .DBFs e indices desengessados da pasta do aplicativo.

Se o aplicativo tem um configurador que designe as tabelas e indices para uma pastaem qualquer lugar ficará mais fácil para mapear, mas o problema não é este e sim, o porque um arquivo de movimento recebe numeros sequenciais 1, 2, 3,...

Se voce possuir acesso ao código poderá entender o porque são criados, quando e como.

Se não tem acesso aos fontes o que se faz é enganar o S.O. e o aplicativo para pensarem existir somente uma maquina. Talvez isto seja considerado uma técnica hacker de tornar um aplicativo mono em compartilhado, pois se for o seu caso só lhe restará isto.

Eu tive de enganar um aplicativo tempos atrás que usava .MDB e tinha uma tabela vinculada engessada em um a pasta, não porque o programador quis criar um impecilho e sim porque vínculos em .MDB engessam os caminhos.

Eu usei um subst no servidor criando uma pasta virtual da real e mapeie na rede esta pasta virtual, ou seja, virtualizei o virtual. Funcionou já que o servidor Linux que tinha o aplicativo tinha parado.

Portanto como os amigos já disseram, comece do básico da configuração pois se o aplicativo rodava antes, agora com a atualização do S.O. provavelmente algumas configurações se perderam.

[Eolo]

Eu tinha um sistema rodando em rede, cada estação com seu EXE local, os DBFs no servidor. Mas eu usava (e abusava) do Tbrowse e, quando 2+ estações acessavam um mesmo DBF, ficava lento pra todas.

A saída: Terminal Service no servidor (Win 2003). Joguei todos os EXEs no servidor e cada estação acessava o seu via Conexão de Área de Trabalho Remota, com um login dedicado. Saía do EXE, derrubava a conexão. Assim, as estações não conseguiam acessar o servidor via Explorer ou outros.

Com tudo rodando no servidor (que nem era tão parrudo), ficou perfeito pra todo mundo. Testado: 3 estações, abrimos o mesmo DBF, grudamos os dedos no page down (no Tbrowse), foi como se cada um estivesse acessando um DBF exclusivo local.

[JoséQuintas]

Continua do mesmo jeito que era no Windows 98.

1) Compartilhar a pasta, mas não apenas pra leitura.

2) Nos terminais mapear a pasta como letra.

3) O atalho tem que usar a letra, e não a pasta

4) Se não usar OSLIB ou equivalente, o EXE vai usar 100% de CPU, o que pode ser problema, seja servidor ou terminal.

5) Clipper não roda em 64 bits.

6)
No W98 não tinha limite
No XP, dependendo da versão, o limite máximo é pra 10 terminais (ou próximo disso)
No W7, dependendo da versão, o limite máximo é pra 20 terminais (ou próximo disso)

Meu último uso do Clipper foi em rede Windows 7 com mais de 10 terminais, sem problema algum.
Tudo no servidor, para sempre poder atualizar automático tudo.
Mesmo esquema até hoje usando Harbour.

[alaminojunior]

Para o caso de não poder linkar com OSLIB e outras bibliotecas, a saída é instalar o TameDOS.
Ele fica residente e sempre que um programa 'em DOS' entra em execução, ele assume a parada.

Testado e aprovado.