clipper 5.2b+exspace 1.0g x clipper 5.2e+blinker7

[aprendiz_ce]

Prezados, bom dia.

Mudei a compilação do meu ERP que era com "clipper 5.2b + exspace 1.0g" para "clipper 5.2e+blinker7" e aparentemente não vi melhoria alguma. Pergunto a vocês: Devo manter a compilação anterior ou a nova compilação? Quais beneficios estarei obtendo caso eu passe a utilizar a nova compilação?

Grato e aguardo comentários.

P.S.: Fez o referido procedimento, mediante leitura de diversos comentários sobre o uso do "clipper 5.2e+blinker7" que encontrei aqui no fórum.

[Jairo Maia]

Olá aprendiz_ce,

Mudei a compilação do meu ERP que era com "clipper 5.2b + exspace 1.0g" para "clipper 5.2e+blinker7" e aparentemente não vi melhoria alguma.

Parabéns... Significa que seu sistema é bem sólido e bem projetado.

Mas como pediu opinião, vou dar a minha:

1-Primeiro: você já ganhou em performance ao mudar para a versão 5.2e do Clipper, que foi a última e mais estável lançada (versão console, nunca usei a versão 5.3, que tinha a ideia de ser compatível com Windows [GUI]);

2-Segundo: mudar para o compilador Blinker, também adicionou melhoria na performance porque ele permite um uso melhor de memória.

Sugestão: Mantenha assim que acho que somente há vantagens...

[JoséQuintas]

Pergunta importante:
Blinker 7 em modo extended? (blinker executable extended search blxclp52)

Uma melhora é não precisar mais de temporários - o RTLink fazia isso
Outra melhora, só usar a função Memory(0) pra ver o quanto tem disponível agora.
O EXE vai poder crescer à vontade.

[aprendiz_ce]

Olá aprendiz_ce,

Mudei a compilação do meu ERP que era com "clipper 5.2b + exspace 1.0g" para "clipper 5.2e+blinker7" e aparentemente não vi melhoria alguma.

Parabéns... Significa que seu sistema é bem sólido e bem projetado.

Mas como pediu opinião, vou dar a minha:

1-Primeiro: você já ganhou em performance ao mudar para a versão 5.2e do Clipper, que foi a última e mais estável lançada (versão console, nunca usei a versão 5.3, que tinha a ideia de ser compatível com Windows [GUI]);

2-Segundo: mudar para o compilador Blinker, também adicionou melhoria na performance porque ele permite um uso melhor de memória.

Sugestão: Mantenha assim que acho que somente há vantagens...

Olá Jairo, bom dia.

Fico feliz em saber que dei uma "turbinada" no meu ERP e que só terei vantagens com isso.

Muito obrigado pelo seu comentário, pois me deixou bem mais seguro.

Pergunta importante:
Blinker 7 em modo extended? (blinker executable extended search blxclp52)

Uma melhora é não precisar mais de temporários - o RTLink fazia isso
Outra melhora, só usar a função Memory(0) pra ver o quanto tem disponível agora.
O EXE vai poder crescer à vontade.

Bom dia, José Quintas.

Pois é, estou usando o "search blxclp52" no meu arquivo de linkedição. Fiz isso devido aos posts que li aqui do fórum, e que na sua maioria usavam esse recurso. Vejo que fiz o "dever de casa" certinho (rs).

Muitíssimo obrigado pela sua atenção, pois me ajuda e muito.

[aprendiz_ce]

Prezados,

Quando fui indexar os arquivos do ERP com a linkedição com exospace, dá um erro de "exausted memory". Quando fui indexar os arquivos do ERP com a linkedição com blinker 7 dá um erro de "general protection fault". E aí, não era para eu ter tido uma melhoria com relação a isso... quando o ERP está linkeditado com o blinker 7, ou não?! Tem como melhor isso?

meu lnk:
BLINKER INCREMENTAL OFF
BLINKER EXECUTABLE EXTENDED
BLINKER EXECUTABLE COMPRESS 1

file <prg principal>
file ...

search c:\clip52e\blinker7\bin\BLXCLP52

LIB \clip52e\lib\CLIPPER
LIB \clip52e\lib\EXTEND
LIB \clip52e\lib\TERMINAL
LIB \clip52e\lib\DBFNTX
LIB \clip52e\lib\DBFCDX

output ERP.EXE


Tambem tentei incluido:

BLINKER HOST DPMI ON
BLINKER HOST VCPI ON
BLINKER HOST XMS ON

mas também não ajudou em nada.

Grato pela atenção e aguardo qualquer orientação.

[Eolo]

search c:\clip52e\blinker7\bin\BLXCLP52

Dá uma checada nesse path...
Ele aponta para a pasta BIN mas, na instalação padrão do Blinker,
o arquivo Blxclp52.lib fica na pasta LIB.

O certo não seria
search c:\clip52e\blinker7\lib\BLXCLP52 ?

[aprendiz_ce]

O path está correto, ou seja, é "search c:\clip52e\blinker7\lib\BLXCLP52" mesmo. Apenas na hora de escrever aqui no fórum, eu errei na digitação (search c:\clip52e\blinker7\bin\BLXCLP52).

[Eolo]

Dei uma pesquisada rápida na net sobre “general protection fault” (coisa que eu não vejo acontecer faz muito tempo...).

http://www.computerhope.com/issues/ch000224.htm

Deste link, saem algumas perguntas. Pra começar, esse seu problema acontece em um PC específico ou em qualquer PC? Se é em um único PC, deve ser problema nele. Qual a versão do Windows? 32 bit? Ou é 64 rodando o ERP em uma máquina virtual? O Windows está 100% atualizado, limpo de viroses etc.? Os drivers de dispositivos estão todos atualizados, sem ressalvas? Já checou a memória RAM (MemTest)? Tentou isolar algum hardware (ou software!) que pode estar com problemas? O HD tá trabalhando com espaço de sobra ou tá no gargalo? Tentou desativar o anti-virus, como teste? Veja mais dicas no link acima...

http://stackoverflow.com/questions/1051 ... rmittently

Neste outro link, que trata de programas de 16 bit rodando em Windows mais atuais, há menção a um erro causado pelo arquivo “win87em.dll”. Dica de correção incluída.

[aprendiz_ce]

Eu já havia feito o "dever de casa", ou seja, verifiquei todos os itens que você mencionou.

Sobre o referido erro... ele ocorre em máquinas distintas. O sistema operacional em questão é Windows XP SP3 - 32bits. Só pra constar: O mesmo já roda nesse "formato" a muitos anos e nunca tive problema algum, e muito menos desse tipo. Até fui mais radical, verifiquei servidor de arquivos, rede elétrica, switchs, cabeamento e tudo está certinho.

[JoséQuintas]

Tente isto:

Código: Selecionar todos

      blinker procedure depth 120
      blinker executable alignment 128

Por acaso, pode ter acontecido de voce ter usado recursividade infinita?
Se fez isso, é corrigir o fonte.
Seria a rotina chamando ela mesma, o que não tem fim... a não ser o erro.

Código: Selecionar todos

mostra( 5 )
FUNCTION Mostra( x )
   RETURN Mostra( x )

Outra situação rara que parece que só eu tive:
Usar campo memo.

[aprendiz_ce]

José Quintas, boa tarde.

Com certeza não tenho nada que cause uma "recursividade infinita". Agora, com relação a campos do tipo memo, eu uso alguns. No caso dos campos do tipo memo, o que exatamente eu posso fazer? Lembrando que o ERP roda a muito anos e nunca tiver problema algum com relação a isso... No caso dos campos memo, pode ser por causa de MUITOS registros nas tabelas/DBFs?

Dúvida sobre:

blinker procedure depth 120
blinker executable alignment 128

O que exatamente esses parametros fazem? Aonde posso encontrar um help de parametros usados pelo blinker?

Grato pela sua atenção e aguardo pelo seu comentário.

[JoséQuintas]

Disse que é erro na reindexação:

Se acontece com os dois linqueditores, e o blinker libera muito mais memória que o exospace.... tem algo mais aí.

Por acaso não criou um índice do tipo Trim( nome ) ?
Isso bagunça o Clipper, porque ele precisa trabalhar com tamanhos fixos, e isso deixa ele "doidinho"... rs
Vai depender do tamanho do primeiro campo que ele pegar como modelo pra dizer quanto ele vai reservar.

O melhor mesmo é tentar identificar aonde acontece, com qual arquivo, etc.

Código: Selecionar todos

? "abrindo arquivo"
use arquivo
? "criando indice xxxx"
index on .....

Quando der erro, vai ver na tela aonde aconteceu.


Nota
Esses dois parâmetros, acho até que são equivalentes, mas na dúvida sempre deixei assim.
Era recomendado pra índice CDX, ele aumenta a "profundidade" de chamadas.
um módulo que cahama outro que chama outro que chama outro... etc... isso tem limite, os parâmetros aumentam o limite.

[Jairo Maia]

Olá Pessoal,

Será que não seria o caso de sugerir que ele abandonasse o modo PROTEGIDO e passasse a usar o modo REAL?

Particularmente, nunca usei o modo protegido, pois só dá problema. Em modo PROTEGIDO o aplicativo é que tenta gerenciar a alocação de memória, já no modo REAL, isso fica por conta do SO (Sistema Operacional).

Eu sugeriria isso...

Nota: Considerando que ele mudou para Blinker.

[aprendiz_ce]

Olá Jairo,

Não é má ideia, mas como exatamente ficaria as linhas de linkedição? Me passe um exemplo de como ficaria o meu *.LNK.

Grato pela sua atenção e aguardo orientações.

[JoséQuintas]

Será que não seria o caso de sugerir que ele abandonasse o modo PROTEGIDO e passasse a usar o modo REAL?

Eu SEMPRE usei o modo protegido, e nunca tive problemas com isso.
Ele está trocando de linqueditor pra tentar resolver o problema que já existe, então não foi o linqueditor que causou o problema,.

Lembro de algum problema ao misturar programas diferentes ao mesmo tempo.
Algo como o Windows ter que configurar a memória pra um ou pra outro.
Não lembro mais, porque foi uma única máquina, em um único lugar, e não teve a ver com meu aplicativo.

Se tem vários programas Clipper, é deixar todos iguais, mesmo linqueditor.

Uma coisa que achei curiosa é juntar NTX e CDX no mesmo programa.
Aliás... nunca usei DBFCDX, fui direto pra SIXCDX.
Também lembro de algum comentário do CDX do 5.3 ser melhor do que o CDX 5.2.
Também não sei se faz uma mistura dentro do programa com isso.

Pode ser até seus arquivos corrompidos, memória do computador, placa de rede, configuração do Windows, etc. etc.

O que acontece mesmo, é que você precisa procurar SUA solução, já que tem acesso ao ambiente que dá o problema.
Colocar pra mostrar certos pontos do programa pra localizar em que parte dá erro.

Pode ser importante também: Como faz essa reindexação? usando um PACK que dá problemas ou de outra forma?

Não tem que inventar possibilidades.
Já identificou que é na reindexação, ok, agora identiifique em que ponto da reindexação, se é sempre no mesmo arquivo, se não é num gráfico que inventou de colocar, etc.
E só ir mostrando a informação na tela, e quando der erro, vai ficar na tela a última operação efetuada antes ou durante o erro.