PC Toledo

Olá aprendiz_ce,

Antes de passar como ficaria o script em modo REAL, faça o teste acrescentando a seguinte LIB em seu script: BLXRATEX.

A lib BLXRATEX, corrige alguns problemas no BLINKER que podem ser causados por LIB´s compiladas com EXOSPACE, no entanto, para que ela funcione ela deve ser a primeira LIB a ser chamada no script, então a coloque antes da lib BLXCLP52, que pelo caminho onde estão as lib´s em seu BLINKER deve ser:

Código: Selecionar todos

LIB c:\clip52e\blinker7\lib\BLXRATEX
search c:\clip52e\blinker7\lib\BLXCLP52

Se ainda não funcionar, passo um script para uso em modo REAL, que a meu ver é preferível.

Pera aí....
Dei uma revisada no post e lembrei de uma coisa.
Esse erro no blinker acontece ao usar índices corrompidos.

Já pensou que os usuários podem estar fechando as janelas no (X) e não deixando o aplicativo atualizar tudo direito?

Repetindo o que eu já disse antes:
Acompanhe seu fonte para ver em que parte está ocorrendo o erro, basta colocar mensagens na abertura de arquivos, criação de índices, etc. pra ver o ponto do problema.
Até mesmo salvar a tela quando der erro, porque os usuários nem sempre avisam quando dá erro.
Coloque isso automático, nem precisa modificar o aplicativo, é até melhor fazer fora dele.

E se costuma usar aquilo de BEGIN SEQUENCE/END SEQUENCE pra esconder erros... é um bom motivo pra não usar mais.

Por enquanto o ponto chave pra mim é:
- Dá erro com EXOSPACE
- Dá erro com BLINKER
Os dois trabalham diferentes entre si, então o problema não é linqueditor.

Nota:
Modo extendido do Blinker, trabalhei desde o Blinker 3.0 até o 7.10 que foi o último, foram pelo menos 12 anos assim sem nenhum problema.

Olá Jairo,

Estarei fazendo o que você recomenda. Vou incluir a BLXRATEX e vê como fica.

Se possivel me mostre um exemplo de um LNK para modo real, pois gostaria de fazer um teste com isso.

Mais uma vez muito obrigado pela sua atenção.

Olá José Quintas,

Sendo bem sucinto! Eu já fiz tudo isso e mais alguma coisa que o amigo recomenda. Afinal, esse ERP roda sem problemas a mais de 15 anos e sempre compilado e linkeditado com clipper 5.2b+exspace 1.0g.

Dúvidas:
1) Eu não misturo NTX com CDX. Uso somente "bolsa de indices" com DBF/CDX. Apenas o compilador me solicita e eu incluo na compilação. Também não uso nenhum tipo de LIB, nem minha e muito menos de terceiros, pois penso que fico livre de possíveis "pendências" no caso de uma mudança de compilador. Há algum erro nisso? Comente.

2) Que tipo de problema um "pack" pode causar nesse momento de reindexar? Só pra constar: Eu não uso o comando "REINDEX", sendo assim, só me resta o "INDEX". Algo de errado nisso? Comente.

3) Eu oriento aos usuários a sempre encerrarem o ERP de forma correta, e nunca abruptamente, mas "usuário" você sabe como é, né?! Como posso bloquear isso? Gostaria de uma solução para proibir o uso botão "X" da janela do Windows. Até já peguei uns ENGRAÇADINHOS dando "ALT+C" no mesmo, mas resolvi com um SETCANCEL(.F.). Eu sempre uso assim, mas em casos de manutenção ativo para uns testes/debugs... daí alguém deve ter visto e passou a usar. (rs)

Comentário:
A única coisa que percebo com relação ao problema de indexação, é quando o volume te registros é muito alta. Fora isso, nada!

Muitíssimo obrigado pela sua atenção e aguardo pela suas orientações e comentários.

Abraço!

quando o volume te registros é muito alta

Diga o que chama de alta.

acrescente OSLIB.LIB e coloque nas primeiras linhas do aplicativo OL_AutoYield(.T.)
Não tenho mais OSLIB.
Isso é para o programa não ocupar 100% de CPU, e deixar o Windows trabalhar.

Não é obrigatório mas pode ser interessante colocar em pontos de parada.
Por exemplo, dentro do loop da GETSYS.

Código: Selecionar todos

DO WHILE ...
...
   OL_Yield()
...

Isso libera tempo ao máximo. Seu aplicativo vai ocupar ZERO de CPU quando estiver em espera.
Caso contrário 100%, ou menos se já estiver com OL_AutoYield(.T.).

OL_AutoYield(.T.) ativa o modo automático
OL_Yield() libera a cada chamada

Explicação:
Para o Clipper verificar teclado (ou mouse se tiver LIB de mouse), ele fica testando o teclado milhares de vezes por segundo.
É isso que causa o uso de 100% de CPU.
Para a gente está parado, mas na prática ele está trabalhando e muito.
Programa em Windows normalmente já considera isso, e tem algo parecido.

Sobre CDX:

Código: Selecionar todos

REQUEST DBFCDX

PROCEDURE Main

RddSetDefault( "DBFCDX" )

Talvez eu tenha me confundindo quanto a linqueditar DBFCDX.
Acho que era a SIXCDX que tinha opção pra retirar DBFCDX.

Talvez possa ser seu próximo teste: SIXCDX.
Seria trocar DBFCDX pra SIXCDX, e acrescentar a LIB.

Aí fica com o mesmo ambiente que eu sempre usei, restando apenas o detalhe o campo MEMO.

EU jÁ TIVE PROBLEMA COM CAMPO MEMO.

Código: Selecionar todos

USE PEDIDOS
INDEX ON CODIGO TO INDICE1
SEEK 5
*** internal error ***

Só porque o campo memo existia.
Acho que já era SIXCDX nessa época.
Não lembro a mensagem exata.
Era volume maior de dados, e muitos usuários, mais de 50.
E nesse mesmo local, na época do W98, ao conectar máquina com W2000, a máquina com W2000 corrompia índices.

José Quintas, boa tarde.

Diga o que chama de alta.

Responder a esse pergunta é muito complicado, pois é muito subjetivo. (rs)
Penso que depois dos 700.000 registros a coisa complica. Sei que o xBase é para suporta coisas pra mais de 1.000.000, só que eu não confio. Falo isso levando em conta o contexto do ambiente, que no meu caso, é misto, e ainda roda remotamente, abrindo sessões dentro de um servidor. Então mesmo sem ter problemas, quando o ERP chega na casa do 700.000 registros... eu fico com o "coração na mão" (rs).
Eu sou da época (jurássica) do DBase II e acompanhei todas essas evoluções do xBase, acho que por isso não sofro tanto. (rs) Então, tomo dos os cuidados possíveis, desde como vou criar as tabelas, seus índices, OS das estações e etc. Mas mesmo assim, fico preocupado, talvez pelas experiências (más) vividas daquela época...

Sobre o OSLIB:
Achei bem interessante. Se eu encontra-la, pois acho difícil! Vou aplicar essa "bichinha" e vê no que dá. Você usa ou já usou?

Sobre o SIXCDX:
Nunca usei não. Nunca tive curiosidade, mas posso dar uma estudada. Só não sei se o SIXCDX é melhor do que o DBFCDX. Confesso que não sei!

Sobre os MEMOs:
Eu sempre usei campos MEMOs e ao contrario do colega, nunca tive problema algum. Acho que o fato se deve aos cuidados que tomo...

Muito obrigado pela sua atenção.

Forte abraço!

Achei OSLIB no site do autor.

http://www.davep.org/clipper/

Detalhe: Também vai afetar o tempo pra reindexação. Pode desativar na reindexação, mas pode ser interessante fazer um teste com ela ativada, pra ver se dessa forma a reindexação flui numa boa.

OL_AutoYield(.T.) -> ela faz a "temporização" automática, assim resolve aonde não temos acesso, como num Inkey(0)
OL_AutoYield(.F.) -> Desativa
OL_Yield() -> Cada chamada libera tempo pro Windows.
Interessante em pontos de espera conhecidos, pra liberar TODA CPU.

Código: Selecionar todos

DO WHILE Inkey() != K_ESC
   OL_Yield()
ENDDO

Só abrir o gerenciador de tarefas, e vai ver a diferença de uso da CPU com o programa Clipper aberto.

Olá Pdrendiz_ce,

aprendiz_ce escreveu:Me passe um exemplo de como ficaria o meu *.LNK.

Para efeito de teste, vejo um script em modo REAL:

Código: Selecionar todos

BLINKER OVERLAY FIXED
BLINKER PROCEDURE DEPTH 120
BLINKER INCREMENTAL OFF
BLINKER OVERLAY PAGEFRAME ON
BLINKER ENVIRONMENT OVERRIDE
BLINKER EXECUTABLE REAL
BLINKER EXECUTABLE CLIPPER E:2048;F:155;SWAPPATHC:\TEMP;
BLINKER EXECUTABLE COMPRESS 1
BLINKER MEMO PACK 60
#
# A linha abaixo deixei comentada. Ela serve apenas se vc tiver o erro 1141, referente
# ao tamanho de paginação. Pode ocorrer com executáveis acima de 1MB. Porém não é regra geral.
# Os valores podem ser 1, 2, 4, 8, 16, 32, 64 e 128.
#
#BLINKER EXECUTABLE ALIGNMENT 128
#
NOBELL
#
OUTPUT ERP.EXE
#
# Liste abaixo seus arquivos .OBJ
#
BEGINAREA
#
FILE <Prg principal>
FILE ...
FILE ...
FILE ...
#
ALLOCATE EXTEND
#
# As LIBs em Clipper, vc coloca aqui. Nem toda Lib pode ser colocada aqui. Se der erro
# em alguma, coloque abaixo de ENDAREA.
#
LIB \clip52e\lib\DBFCDX
#
ENDAREA
#
SEARCH CLIPPER
BEGIN AREA
MOD accept, acopy, adel, ains, appexit, appinit, atail, cmem, dbcmd0
MOD dbcmd1, dbcmd2, dbcmd3, dbcmd4, dbcmd5, dbcreate, dbgapi, dbgshado
MOD dbnubs, dbstruct, delimdyn, diskio, dlm0, dlm1, emmalloc, emmcount
MOD emmfree, emminst, emmpage, emmreall, emmstat, emmvers, errsys0
MOD exactcmp, getenv, gets0, gets1, gets2, gx, initexit, instd, joinlist
MOD lupdate, memory, mrelease, msave, oldbox, oldclear, outstd, philes
MOD rddord, rddsrv, run, saverest, scroll, sdf0, sdf1, sdfdyn, send, seq
MOD sortof, squawk, startsym, tb, version
ENDAREA
SEARCH TERMINAL

Não entendi muito bem esse script.
Me deu a impressão de que espreme ao máximo o Clipper, pra liberar memória, e depois desperdiça tudo.

Overlay é o seguinte: você decide que pedaço do programa vai ser carregado em determinado espaço de memória.
Menu chamada os módulos, tem módulo que é usado sozinho, outros acompanhados.

Então obrigatóriamente o menu vai estar na memória, os outros nem sempre.

Código: Selecionar todos

BEGINAREA
   MENU
  ROTINAGERAL
ENDAREA
BEGINAREA
   CLIENTES
   FORNECEDORES
   PRODUTOS
ENDAREA

Desta forma, clientes, produtos e fornecedores nunca vão ser carregados ao mesmo tempo, o que economiza memória.

Quanto mais conhecer os módulos/bibliotecas, mais pode ter console sobre isso.

o MOD é pra especificar módulos das LIBs que também serão afetados pela divisão.

Se baixou do link que indiquei, a pasta CLP é exclusiva pra uso com Clipper.
Também contém subpastas, por exemplo esta

Código: Selecionar todos

 Pasta de d:\TOOLS\blinker\CLP\LNK

28/10/2016  22:59    <DIR>          .
28/10/2016  22:59    <DIR>          ..
01/01/2003  07:00             1.307 CDX520.LNK
01/01/2003  07:00             2.784 CL501MAX.LNK
01/01/2003  07:00             2.643 CL501MID.LNK
01/01/2003  07:00               887 CL501MIN.LNK
01/01/2003  07:00             6.090 CL520MAX.LNK
01/01/2003  07:00             4.951 CL520MID.LNK
01/01/2003  07:00               949 CL520MIN.LNK
01/01/2003  07:00             4.904 CL530MAX.LNK
01/01/2003  07:00             4.012 CL530MID.LNK
01/01/2003  07:00             1.849 CL87MAX.LNK
01/01/2003  07:00             1.650 CL87MID.LNK
01/01/2003  07:00               540 CL87MIN.LNK
01/01/2003  07:00               877 MDX520.LNK
01/01/2003  07:00               844 NDX520.LNK
01/01/2003  07:00               846 NTX520.LNK
              15 arquivo(s)         35.133 bytes

No meu ponto de vista, supondo que conseguisse liberar toda memória, o que é impossível, conseguiria 640KB.
Tantos detalhes pra liberar menos de 640kb, sendo que pode ter 16MB em modo protegido.

Pode tentar pesquisar também no manual do blinker.
O link que passei também contém o manual.
De repente pode encontrar algo lá que não vimos na época.
Só não sei se compensa todo esse trabalho nos dias atuais, já que no final de tudo vai acabar usando o Harbour.
Apenas está deixando de aproveitar esse tempo que está gastando.

Tenho um aqui que dá pra comparar com o seu.

Código: Selecionar todos

 Pasta de d:\JPA\guia

29/12/2014  13:35       190.640.640 GUIA.CDX
29/12/2014  13:35     1.613.595.009 GUIA.DBF
               2 arquivo(s)  1.804.235.649 bytes

É a lista telefônica de todo estado de São Paulo, com milhões de registros.
Eu evitava ao máximo ter que reindexar isso aí, mas já não lembro se tinha algum problema.
Mas só era usado na minha máquina.
Ainda tenho aqui, mas faz muito tempo que não uso mais.
E quando usava era muito eventual.

lógico, foi uma das coisas onde testei com Harbour, no início do uso dele.

Pra quem não viu, tem até a parte de desenvolver pra Windows, usando Clipper..

JoséQuintas escreveu:Achei OSLIB no site do autor.

http://www.davep.org/clipper/

Detalhe: Também vai afetar o tempo pra reindexação. Pode desativar na reindexação, mas pode ser interessante fazer um teste com ela ativada, pra ver se dessa forma a reindexação flui numa boa.

OL_AutoYield(.T.) -> ela faz a "temporização" automática, assim resolve aonde não temos acesso, como num Inkey(0)
OL_AutoYield(.F.) -> Desativa
OL_Yield() -> Cada chamada libera tempo pro Windows.
Interessante em pontos de espera conhecidos, pra liberar TODA CPU.
Código: Selecionar todos
DO WHILE Inkey() != K_ESC
   OL_Yield()
ENDDO
Só abrir o gerenciador de tarefas, e vai ver a diferença de uso da CPU com o programa Clipper aberto.

José Quintas, bom dia.

Nossa, achei super legal esse sua dica de uso da OSLIB. Pena que o link passado não abrir nem com reza forte! (rs)

Dúvidas:
O exemplo com esse "while" se aplica a qualquer tipo de processo/loop/copys que o sistema possua, é isso? Ou é um teste somente voltado ao toque do teclado?

Muito obrigado pelo seu enpenho em me ajudar.

Forte abraço!

Jairo Maia escreveu:Olá Pdrendiz_ce,

aprendiz_ce escreveu:Me passe um exemplo de como ficaria o meu *.LNK.

Para efeito de teste, vejo um script em modo REAL:

Código: Selecionar todos

BLINKER OVERLAY FIXED
BLINKER PROCEDURE DEPTH 120
BLINKER INCREMENTAL OFF
BLINKER OVERLAY PAGEFRAME ON
BLINKER ENVIRONMENT OVERRIDE
BLINKER EXECUTABLE REAL
BLINKER EXECUTABLE CLIPPER E:2048;F:155;SWAPPATHC:\TEMP;
BLINKER EXECUTABLE COMPRESS 1
BLINKER MEMO PACK 60
#
# A linha abaixo deixei comentada. Ela serve apenas se vc tiver o erro 1141, referente
# ao tamanho de paginação. Pode ocorrer com executáveis acima de 1MB. Porém não é regra geral.
# Os valores podem ser 1, 2, 4, 8, 16, 32, 64 e 128.
#
#BLINKER EXECUTABLE ALIGNMENT 128
#
NOBELL
#
OUTPUT ERP.EXE
#
# Liste abaixo seus arquivos .OBJ
#
BEGINAREA
#
FILE <Prg principal>
FILE ...
FILE ...
FILE ...
#
ALLOCATE EXTEND
#
# As LIBs em Clipper, vc coloca aqui. Nem toda Lib pode ser colocada aqui. Se der erro
# em alguma, coloque abaixo de ENDAREA.
#
LIB \clip52e\lib\DBFCDX
#
ENDAREA
#
SEARCH CLIPPER
BEGIN AREA
MOD accept, acopy, adel, ains, appexit, appinit, atail, cmem, dbcmd0
MOD dbcmd1, dbcmd2, dbcmd3, dbcmd4, dbcmd5, dbcreate, dbgapi, dbgshado
MOD dbnubs, dbstruct, delimdyn, diskio, dlm0, dlm1, emmalloc, emmcount
MOD emmfree, emminst, emmpage, emmreall, emmstat, emmvers, errsys0
MOD exactcmp, getenv, gets0, gets1, gets2, gx, initexit, instd, joinlist
MOD lupdate, memory, mrelease, msave, oldbox, oldclear, outstd, philes
MOD rddord, rddsrv, run, saverest, scroll, sdf0, sdf1, sdfdyn, send, seq
MOD sortof, squawk, startsym, tb, version
ENDAREA
SEARCH TERMINAL

Olá Jairo, bom dia.

Agora me lembro o que exatamente seria "modo real" que você mencionava. Eu usei muito isso no passado, na época do SUMMER'87 + MS-DOS + PC 286/386 + Novell. Era super legal! Eu chama simplesmente de OVERLAYs, ou seja, compilar para uso de OVERLAYs. O problema é que na hora de cria-los qualquer rotina que não esteja dentro do OVERLAY que foi carregado o EXE trava. Claro que isso vai depende de como as rotinas, funções e etc estão "arrumadas". Mas é bem legal esse recurso. Vou dá uma testadinha nisso.

Mais uma vez obrigado pela sua pronta atenção para comigo.

Abraço!

JoséQuintas escreveu:Pra quem não viu, tem até a parte de desenvolver pra Windows, usando Clipper..

caclipper.png

Muito legal isso. Nunca mexi com isso não, mas já tinha ouvido falar.

Tenho um aqui que dá pra comparar com o seu.

José Quintas,

Entendo a sua colocação/comparação, mas penso que uma tabela de CADASTRO (Ex: Clientes) é bem diferença de uma tabela de MOVIMENTOS (Ex: itens de pedidos). Falo levando em conta que a segunda ao longo do uso do sistema é "manipulada" de varias maneira inimagináveis, ao contrário da outra que na maioria das vezes é usada somente como CONSULTA e assim a sua integridade (DBF/NTX/CDX) tende a se manter por mais tempo ou até mesmo por toda a sua vida.

Não sou dono da verdade, mas é o meu modo de ver. Se possível comente.

Aquele abraço!

A comparação foi quanto a tamanho de arquivo DBF.

Aqui o link abre normalmente.

Acabei baixando duas, e só percebi na hora de enviar pro site, são de versões diferentes.
Não sei qual exatamente enviei pra seção de download.

deixei aqui também: http://www.jpatecnologia.com.br/arquivos/oslib106.zip

Limite-se ao uso das duas funções que passei.
Copiar/colar e outras coisas dependeria de funcões externas, melhor nem mexer com essa parte.
Mas tem até manual em formato NG.

Em todo caso, aqui também:
http://www.davep.org/clipper/OSLib/ng20d.html

Aqui o site abre normalmente.
A parte do manual, apesar de ter o NG no ZIP.

PC Toledo

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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