Erro que não consigo identificar o motivo!

[ANDRIL]

Pessoal, criei uma rotina para enviar o erro ocorrido no cliente para meu email. Tenho recebido um erro estranho:

IDENTIFICAÇÃO DO ERRO
Error BASE/1003 Variable does not exist: DESCRICAO
Arq. em Uso: nenhum Ordem: nenhuma
Argumento Funcao: NIL
Erro a Nivel Sistema DOS.: 0
Nome do SubSistema.......: BASE
Erro a Nivel Subsistema..: 1003
Codigo do Erro Generico..: 14
Numero de Vezes da Falha.: 1
Numero do Erro...........: 2
Possibilita DEFAULT......: NAO
Possibilita RETRY........: SIM
Pos.Subst. Erro p/ Valor.: NAO

LISTA DAS ÚLTIMAS FUNÇÕES
Funcao: (b)MYDBEDITAGEDBF5(7829)
Funcao: TBROWSE:READRECORD(0)
Funcao: TBROWSE:STABILIZE(0)
Funcao: MYDBEDITAGEDBF5(7919)
Funcao: AGEDBF5(1161)
Funcao: MYDBEDITPRINCIPAL(3247)
Funcao: MAIN(5260)

MYDBEDITAGEDBF5 é uma função que monta um TBROWSE e dela são chamadas outras funções conforme as teclas Fs, F1.CLIENTE, F9.SERVIÇOS etc.
O erro reporta nenhum arquivo aberto, DESCRICAO é um campo do arquivo que é utilizado na montagem do TBROWSE da tela de pedidos, e o erro acontece neste código:

brw:addcolumn(tbcolumnnew(cp_titu,&("{||TRAN("+cp_+",["+cp_masc+"])}")))

ou seja, no momento da criação do TBROWSE. Porem notei que independente de usar os Fs o TBROWSE é criado no inicio, não entendo por que
esta dando erro lá no começo sendo que não volta ao inicio dele.

Na abertura da função que cria o TBROWSE já coloquei a verificação se o arquivo DBF esta aberto (disponível) caso negativo, abro ele.

Código: Selecionar todos

IF SELECT("PRODUTO")=0
	do while abrearea("PRODUTO")=.F.
	enddo
ENDIF

Ou seja, não tem como dá erro sem o arquivo aberto conforme aparece no log de erro.

O que notei foi
- acontece em máquinas da rede, não lembro de ter ocorrido no servidor.
- acontece no TBROWSE, coincidentemente é a tela que mais é usada no sistema pois é a de pedidos.

Alguma idéia?

[Itamar M. Lins Jr.]

Olá!
Queda de conexão.
Isso ocorre até com LetoDb ou qualquer coisa pq a conexão caiu.
Não acontece no servidor pq a conexão não existe. Não passa pela placa de rede ou WIFI.
Se usar IP fixo pode diminuir o problema.
Tem que mexer no HUB/Modem editar para jogar a faixa de IPs dos celulares para 192.168.1.101 por exemplo, e usar abaixo de 192.168.1.99 até 192.168.1.2 para a rede.
Toda vez que entra um cel na rede muda a faixa de IP e cai a conexão das máquinas. Tem acontecido muito isso, e pessoal não percebe.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

MYDBEDITAGEDBF5 é uma função que monta um TBROWSE e dela são chamadas outras funções conforme as teclas Fs, F1.CLIENTE, F9.SERVIÇOS etc.
O erro reporta nenhum arquivo aberto, DESCRICAO é um campo do arquivo que é utilizado na montagem do TBROWSE da tela de pedidos, e o erro acontece neste código:

Vários arquivos... ALIAS errado?

Código: Selecionar todos

IF SELECT("PRODUTO")=0
   do while abrearea("PRODUTO")=.F.
   enddo
ENDIF

Abriu na área certa? ou fechou o que estava aberto?
Colocou algo muito problemático, do while sem tempo de espera.

É normal quando dá erro no tbrowse, conforme o caso, ele apontar para a criação do array.
Não é que ele volta ao início, está mostrando que o problema pode ter sido na criação do array, ou relacionado ao seu conteúdo.

[ANDRIL]

Queda de conexão.

Pois é, suspeitei logo de cara. Então no momento que erro ocorre verifico a conexão e geralmente caiu, da erro 53 ou 64 que são erros de rede.
Há casos que o teste de rede retorna rede ok e mesmo assim o erro aconteceu. Meu teste de rede, é tentar criar o arquivo com FCREATE() no servidor e trato o retorno para saber se teve exito ou não, se teve exito, indica que o servidor esta disponível na rede.

Abriu na área certa? ou fechou o que estava aberto?
Colocou algo muito problemático, do while sem tempo de espera.

A primeira vista, José o trecho sugere este tipo de falha. Mas na verdade, a função abrearea() tem todo tratamento, inclusive com inkey(1) entre as tentativas de abertura do arquivo. Quanto ao nome e alias, estão certos.
É um erro esporádico, acontece em alguns clientes e outros não, ou pelo menos, demora muito a acontecer. O problema é descobrir o motivo real para tentar dar uma solução.
Já estou buscando a identificação disto a algum tempo mas sem êxito.

[Itamar M. Lins Jr.]

Olá!

Há casos que o teste de rede retorna rede ok |

Isso não vem ao caso. Pq a conexão vai e volta.
Não é erro do seu aplicativo, pq vc já disse que em outros clientes está ok.
É defeito "INTERMITENTE" na rede.
Use IP FIXO pois AMENIZA o problema. Pode ser atualizações, antivírus, falha no cabo quando mexe no fio, etc. Mas é defeito que não é no seu programa.
Não use rede mapeada. Use LetoDbf.
Se abre do DO WHILE etc.. não tem problema nenhum pq funciona em outros locais e no servidor.
Não acha o problema pq no servidor e em outros lugares o erro não ocorre ou se ocorre é com pouca frequência.

Error BASE/1003 Variable does not exist: DESCRICAO

Tá na cara que não é erro do seu aplicativo.
Quando dá erro em rede até o DBSEEK dá erro, SELECT, etc.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Tem uma outra coisa:

Tem usuário que vai almoçar e deixa o aplicativo aberto.
Se não fecha o aplicativo depois de 15 minutos, por default a rede desconecta o terminal.
No retorno a rede reconecta, mas leva tempo, e o Harbour não espera.
Poderia explicar não ter mais nada aberto.

Em todo caso, pode fazer testes simples, por exemplo, ao invés de usar DESCRICAO, usar cliente->Descricao
Se isso resolver nessa parte, significa que o problema é ALIAS, e investiga as rotinas se estão retornando ao ALIAS anterior.

Código: Selecionar todos

FUNCTION Alguma()
   LOCAL nSelect := Select()
 ....

   SELECT ( nSelect )
   RETURN Nil

Com certeza uma saída interna não vai retornar à área anterior.

Código: Selecionar todos

FUNCTION Alguma()
   LOCAL nSelect := Select()
   SELECT x
   IF .T.
      RETURN Nil // aqui retornaria sem retornar o ALIAS
   ENDIF
   SELECT ( nSelect )
   RETURN Nil

Outra coisa: preste atenção no comando SELECT, não se trata da função Select()
SELECT (nSelect)
não é a mesma coisa que
Select( nSelect )

O primeiro é o comando SELECT, pra mudar a área atual
O segundo é a função Select(), que apenas retorna o número da área atual, e não faz mudança nenhuma.
Então, espaços fazem muita diferença.

[JoséQuintas]

Ainda sobre a rede desconectada por tempo:

Isso explicaria ora a rede estar ok, e ora não.
O Windows estaria se reconectando à rede, leva um tempo, e de repente pode ter se reconectado só na hora de mostrar o erro.
Tem a reconexão do terminal, a reconexão do mapeamento, etc.
Isso não vai ser sempre igual, porque depende do usuário apenas fazer o terminal voltar, ou já sair apertando teclas.
E também do tempo entre uma coisa e outra.

[ANDRIL]

É defeito "INTERMITENTE" na rede

É o que acredito que seja.

Outra coisa: preste atenção no comando SELECT, não se trata da função Select()
SELECT (nSelect)
não é a mesma coisa que
Select( nSelect )

Neste caso daria erro mais vezes e seria mais fácil indentificar.

Se não fecha o aplicativo depois de 15 minutos, por default a rede desconecta o terminal.

Tem algum local no Windows que impeça de ocorrer isso com a rede?

Tenho clientes com várias máquinas na rede, umas mais utilizadas que outras, umas são ligadas entram no sistema e esquecem, passam mais de 15 minutos e não vi ocorrer este problema de desconectar rede, ocorre sempre esta desconexão? Depende da versão do Windows?

[Itamar M. Lins Jr.]

Olá!

Se não fecha o aplicativo depois de 15 minutos, por default a rede desconecta o terminal.

Isso ai como dizia o padre Quevedo "Non eqziste" em rede normal. Isso é em uso RDP acesso REMOTO!

passam mais de 15 minutos e não vi ocorrer este problema de desconectar rede,

Isso é para conexão com SGBD ou acesso remoto.
Com mapeamento e com LetoDBf, pode deixar DIAS ligado que não desconecta. Só se mudar o IP.
A conexão não cai. Se for assim com SGBD(MySQL) mais um motivo para continuar usando LetoDBf pq não tem esse problema.
Se a conexão cair a cada 15/30 minutos de inatividade ? Acredito que isso é improvável. Pelo menos com rede mapeada e Letodb repito nunca vi.

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Isso ai como dizia o padre Quevedo "Non eqziste" em rede normal. Isso é em uso RDP acesso REMOTO!

Isso é questão de segurança.
Em rede com domínio é obrigado inclusive a fazer um novo logon.

Tem também o gerenciamento de energia, que deixa as máquinas em modo de hibernação.

O cara vai almoçar, ou vai embora, e fica tudo em aberto?
Que segurança seria essa?
E vai ficar desperdiçando recursos do servidor?

Se o letodb fica testando comunicação, pra impedir que caia, isso é outra história, não há parada nem se deixar a estação parada.

[JoséQuintas]

Não encontrei a definição do Windows.
Mas basta dizer que a recomendação é 15 minutos.
Senão, ele estará sujeito até a invasão de hackers.

[Itamar M. Lins Jr.]

Ola!

Isso é em uso RDP acesso REMOTO!

Leu ?
Pq acesso via LOGON, nem de computador bom precisa. Nem REDE boa. Qualquer estrutura MINIMA funciona.
Mas rede mapeada ou acesso via TCP(LetoDb/MySql), precisa de REDE boa.
Nem fica deslogando ninguém pq não tem ninguém logado.
O problema é o protocolo SMB de compartilhamento cheio de defeitos, que a rede mapeada usa ou qualquer coisa que faça uso do SMB.

Saudações,
Itamar M. Lins Jr.

[ANDRIL]

De quando postei este tópico para cá, um cliente começou a agravar a situação, começou a dar erro em várias telas iguais ao relatado por mim, acusando erro de variável que seria o campo do arquivo, porem o arquivo acusando fechado sem motivo.

Acompanhei pelo remoto e o sistema parado sem o usuário mexer, enquanto estava no TBrowse sumiu o cursor (a tarja preta) e com um tempo apareceu na barra SISTEMA NÃO RESPONDENDO ficando travado.

Fiz loop de ping para o servidor de mais de um PC e a conexão ok, rápida e sem perda alguma. Deixe uns 20 minutos pingando e tudo certo.
Recentemente instalaram alguns programas, esses de sites que aceitam pedidos online e obrigam a abrir pelo navegador o site deles, notei que é pesado porque ficam a cada n segundos fazendo a vistoria a procura de novos pedidos. Isso pode ter influenciado de alguma forma.

O fato é que formataram todos os PCs e aparentemente melhorou bastante (detalhe não reinstalaram todos os programas deles), acontece ainda o primeiro erro que relatei mais até agora com pouca frequência. Suspeito de um dos PCs esta com problema ou na placa de rede ou em outro componente que acaba interferindo junto ao servidor, alias tinha um PC que digita A e entrava AAA, ou seja, repetindo letras mesmo trocando o teclado não resolveu.

Enfim, ocorreu tudo isto então fica a dúvida do que realmente pode ser. Vou acompanhar este cliente e vou postando aqui o que for descobrindo.