PC Toledo

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.

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:

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.

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.

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.

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.

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.

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.