PC Toledo

Olá amigos.

Minha aplicação é hoje um ERP em uso normal em diversos clientes mas em apenas um deles está dando problemas.

A aplicação é startada via TS, mas eventualmente "pára de responder", aí tenho que dar logoff da estação no servidor... então o óbvio acontece: os índices CDX são corrompidos...

Preciso resolver isso mas estou elimando hipóteses... uma delas é o Terminal Server, já que nos demais clientes tem usado startando o executável via atalho de programa..

A configuração do cliente em si já é bem complexa:

- 2 PCs duocore 2GbRam HD 160 SATA, um é servidor windows 2003 para usuários, o outro é só para dados.

- são 10 estações, 2 delas ligadas a um roteador wireless, uma impressora HP laser está neste wireless tb. As demais são cabo de rede ligado a um switch. (marcas dos equipo? tudo xing-ling... )

- 2 estações são uma coisa que nunca tinha visto: uma placa que "divide a CPU" e nesta placa pode pôr teclado/mouse/monitor que "vira um pc" (eu estou querendo "queimar" esta placa... rsss)

Enfim amigos: quem tiver experiencia em TERMINAL SERVER com Windows 2003 me dá umas dicas...

Abração a todos do fórum.

tudo xing-ling... )

- 2 estações são uma coisa que nunca tinha visto: uma placa que "divide a CPU" e nesta placa pode pôr teclado/mouse/monitor que "vira um pc" (eu estou querendo "queimar" esta placa... rsss)

Apesar de nunca ter usado TS, (até vou tentar um dia) arriscaria dizer, segundo os post´s dos colegas a respeito de TS, que o problema está neste "arsenal tecnológico' aí.
Pessoalmente, iniciaria montando uma rede simples, mesmo sendo wireless, e ver no que daria.

Obs.: Já tive e ví alguns colegas apanharem destes roteadores e switches "xing ling".

Caro amigo,

Com certeza o problema está por aí mesmo, nós como profissionais de T.I. sabemos disso, meu problema é que preciso de ARGUMENTOS técnicos e precisos.

Politicamente como vou dizer ao cliente que o que ele comprou, instalou (investimento) é parte do problema? Ele está acusando o nosso aplicativo, mas temos 1 cliente usando até 25 estações em 8 lojas diferentes tudo via TS via speedy (ADSL) e sem engasgo.

E peço aos que lerem este tópico se puderem referenciar artigos técnicos, labtests de revistas, etc... será de muito bom grado..

Abraços a todos.

Com certeza o problema está por aí mesmo, nós como profissionais de T.I. sabemos disso, meu problema é que preciso de ARGUMENTOS técnicos e precisos.

Me perdoe pela falta destes. Mas....

Politicamente como vou dizer ao cliente que o que ele comprou, instalou (investimento) é parte do problema? Ele está acusando o nosso aplicativo, mas temos 1 cliente usando até 25 estações em 8 lojas diferentes tudo via TS via speedy (ADSL) e sem engasgo.

Notou que vc já tem o argumento ? Antes de convencer o cliente, vc precisa convencer a sí próprio.

Acredito que até exista argumento técnico que justifique o problema. Entretanto, ele pode ser tão caro de obter quanto todo o maquinário da empresa. Inviável.

Então aí entra a argumentação diplomática. Usando esse mesmo exemplo do cliente que tem 25 máquinas e tem tudo funcionando perfeitamente, você pode jogar isso para o cliente e mais: tentar agendar uma visita deste ao cliente satisfeito, se isso for possível. Ele vendo tudo funcionando com a mesma "base" de software, você passa a não ser visto mais como o vilão da história, mas um aliado na busca da solução.

No passado já tive esse tipo de problema, mas de outra natureza. Com o argumento "Em X clientes, que usam o mesmo sistema, tudo funciona perfeitamente. Só aqui dá problema." já deixei o cliente com a pulga atrás da orelha e sem chance de contra-argumentar. Claro que isso só funciona se o sujeito for razoável e civilizado. Se for casca-grossa ele pode dizer: "Não tenho nada com os seus outros clientes. Meu problema é aqui. Resolva".

Aí o jeito é usar a velha ferramenta da tentativa e erro. Isolar áreas da rede e observar o comportamento. Desconectar segmentos, reconetá-los, etc. Até que uma hora, creio eu, tudo vai funcionar. Aí você terá o problema mais precisamente identificado.

Mas uma coisa é certa. Se o TS não apresenta problema e seu software também não, o problema só pode estar no hardware ou no software relativos à rede.

Amigos,

Grato pelas palavras.. na verdade como vcs perceberam o problema envolve uma parte política e outro técnica.

Mas o fato é: Eu não sei onde está dando certo no cliente "X" como também não sei o que está dando errado no "Y". Isso faz da ciência da computação uma coisa esotérica, uma conjunção de astros e signos ascendentes.

Por isso estou em busca de argumentos técnicos. Preciso da noite para o dia saber o que dá certo em TS e o que dá errado também...

Estou desde ontem a busca deste tipo de argumentação porém a vastidão de sites está dificultando um pouco.. muita informação, pouca resposta...

A parte política vcs tem razão! depende de mim com certeza... mas a parte técnica tá dificil mesmo...

Com certeza filosofia já está ajudando... A filosofia vai ficar melhor ainda com uma cervejinha e uma porçãozinha... rsss

Até mais!

Tenho varios clientes com TS funcionando ok.


Porem tinha um que esta com TS e uma estação em wireless, dava problema de indices sempre.

desligamos o terminal em wireless e acabaram os problemas.

Não seria o caso do seu cliente.

Desative os terminais em wireless para ver se são eles.

Foi isso o que comentei. O ideal, a meu ver, é primeiro tirar o "dele" da reta. Em seguida, fazer experiências, isolando as coisas "esquisitas" pra ver que bixo dá. Argumentação técnica, de verdade, é muito difícil. Podem vir mil teorias, mas o que vale é a prática. Informática, seja software ou hardware, tem um cunho altamente empírico. Fazer o quê? Mãos à obra.

Caros amigos,

As primeiras respostas estão aparecendo..

Nosso ERP usar DBF com ADS (Advanced Database Server) na versão 7 e o driver que ele usa é o padrão Fox16 e não o Fox32 próprio do Visual Fox Pro.

Até aí tudo bem, o problema é que o ADS trata as requisições para as tabelas de forma diferente, por exemplo se fizer uso de outra ferramenta para acesso aos dbfs (que é o que andaram fazendo lá).

Se algum operador usa uma outra ferramenta para visualizar os dbfs o ADS entende que ele deve dar LOCK nesta tabela. Aí nosso ERP não "entende" porque é lock diferente do que é dado na linguagem e fica em deadlock tentando obter acesso, neste momento ele se "perde" e aplicação trava e as consequencias acontecem...

Solução: proibimos o acesso aos dbfs sem ser nossa própria ferramenta por dentro do ERP e com acesso somente ao administrador.

Conforme vou desenrolando os nós vou passando a vcs...

Até mais.

Um usuário "xereta" pode causar um transtorno imenso. Se for isso mesmo, você deveria cobrar pelo transtorno causado. Assim o infeliz realmente aprenderia a não meter o bedelho onde não é chamado.

Caro Maligno...

Apenas para constar nos autos:

O usuário xereta é filho do dono da empresa. Este mesmo pai pagou uma faculdade carissima de ciencia da computação para o mesmo. E é o filho do dono que contratou nosso ERP, monta máquina, etc...

Tô bem nessa foto, né? rssss

Até mais.

Ih, quando o "xereta" é o próprio dono e contratante as coisas ficam piores. Então apenas diga cordialmente que ele cometeu um "equívoco". ))

Ah sim... um pequeno equivoco... rsss... nada para fazer alarde, muito menos contar ao pai dele... rsss

Agora mais respostas técnicas.

Descobrimos também alguns fatores que estão dando problemas.

Exemplo, no ADS o estilo de filtro tem que ser diferente:

nCondFunc := 3
dbSetFilter( "codfunc==nCodFunc")

no ADS isso não pode, pq o filtro é aplicado direto server então ele não entende a variável.

tem que ser assim:

dbSetFilter( "codfunc== " + Str(nCodFunc,10) )

Isso é o que funciona e também se aplica a SET FILTER TO

Até mais.