ActiveDelphi

[profase]

Minhas saudaçoes à todos.
De Inicio, gostaria de parabenizar o maravilhoso produto chamado APOLLODB.
É fantastico...

Sobre o problema,
Peço que olhem com carinho este problema pois,
NÃO SABEMOS MAIS O QUE FAZER! PRECISAMOS IMENSAMENTE DE AJUDA!
NÓS REZAMOS PARA QUE SEJA ERRO NOSSO E VOCES NOS AJUDEM DANDO UMA LUZ DE SABEDORIA!

Resumindo o Problema:
Quando duas ou mais aplicacoes em DOS e WINDOWS compartilham a mesma base de dados DBF num ambiente de rede,
ha corrupcao de dados, causando erro em novas aplicacoes ao abrirem essas mesmas base de dados.E tanto
faz se for applicaçoes em DOS(Clipper+Six) ou WINDOWS(Delphi+ApolloDB). Este erro somente acontece quando
novas apps sao abertas nas estacoes, as que ja estao rodando nao sao afetados pelo erro.

Detalhes em LEIAME.TXT, fonte:
Faça download desse arquivo: www.profase.com.br/ftp/ERROR_1010_1012_Portugues.zip
Nele, estamos enviando juntos um vídeo explicando o problema e um pequeno projeto em DELPHI, com fidelidade
das rotinas e funções idênticas ao projeto principal (pois é muito longo) ... contendo
as aplicações compiladas (DOS + WINDOWS) e seus respectivos arquivos DBF + NSX e DLL.

Muito obrigado pela sua atenção e paciencia...
Aqui nós estamos torcendo pra uma solução deste problema, pois a sobrevivencia dos nossos empregos
e da nossa empresa esta em jogo.
Até breve...

Paulo Ricardo Martinez.

Obs: Solicitamos suporte da própria ApolloDB, mas não tivemos retorno até o presente momento.

[strak2012]

Clipper, é coisa de legado mesmo!

É o seguinte, os DBF quando eram manipulado pelo Clipper o mesmo bloqueava a escrita neste mesmo dbf deixando apenas o dbf disponível para leitura, isso pq duas aplicações não poderia estar escrevendo no mesmo arquivo dbf ao mesmo tempo.

A questão que fica é então como que ele trabalhava com varias estações.

Dois senários era colocado:

1º Um arquivo temporário era criado contendo as alterações e posteriormente quando o dbf estava disponível para a escrita então era atualizado, o problema deste é o sincronismos dos dados, pois com vários arquivos temporário vai la saber qual a ordem das operações, contudo havia sempre quem fizeste esta atualização quase sem erro (aqui as aplicação quase sempre manita os dbf aberto o tempo todo, acumulava então muitos arquivos temporários).

2º As aplicações eram produzidas de forma a reconhecer que os dbf estava em uso no exato momento da operação e assim ficava a aguardar o dbf ficar disponível para realizar a tal operação. (aqui as aplicações não mantem os dbf sempre aberto)

Produzir uma aplicação com delphi para manipular DBF que possa estar em uso por outras aplicações seja ela DOS ou Windows, vai depender muito como estar as demais aplicações que estar fazendo concorrência na escrita deste dbf, se todas as estações estiverem fazendo uso da aplicação delphi neste caso você pode criar recurso mencionado no senário 2º acima ou fazer uma aplicação servidora o qual só ela escreve nos dbf e as demais aplicações se liga ao esta aplicação servidora.

exemplo:
aplicações clientes (estações) <-> aplicação servidor <-> DBFs
_________________
Tudo podemos quando tudo sabemos!

[johnny-walker]

Amigo, tentei abrir este dbf, tem certeza que é um dbf padrão, aqui diz que o header está corrompido.


Claro que o seu tipo de dbf tem índice nsx, não sei, talvez não tenha conseguido por causa disto.



bye
_________________
P.O.W.E.R B.Y D.E.L.P.H.I

[strak2012]

[johnny-walker]

Um conselho como eu e Strak não conseguiu ver se a tabela tem algum problema, já pensou em criar uma estrutura idêntica e migrar os dados para ver se está tudo ok com os dados e a tabela.

Uma coisa veio-me a mente e que pode ter muito sentido o que o Strak falou, visto que o que pode estar acontecendo é que o registro não está sendo liberado do status de escrita e por isto entra em dead lock.
Um fator para pesquisar, verifique a respeito disto que talvez ajude.


Outra possibilidade é migrar o sistema aos poucos com um banco de dados robusto, mas acredito que você esteja a fazer isto.




bye
_________________
P.O.W.E.R B.Y D.E.L.P.H.I

[strak2012]

Acredito que não, pelo que me parece ele estar a implementar recursos em um sistema legado feito em Clipper, que precise acessar e alterar registro num DBF compartilhado com o tal sistema em Clipper.

E isso sim é uma dor de cabeça, pois não se sabe como o programa em Clipper estar a tratar os DBF logo há muitas chances de ocorrer Corrupção dos dados.


Das solução seria:

1º - Migração (Recomendado)
Matar o sistema em clipper e criar um outro do zero fazendo a migração dos dados contido no DBF para uma estrutura de banco mais robusto

2º - Trabalhar com a aplicações delphi apenas para consulta
Trabalhar com backup dos dbf em seu novo recurso, as aplicações delphi neste caso só poderia consultar, pois o sistema em clipper é que realiza as alterações, um backup dos DBF era realizado para um outro diretório o qual o programa delphi estaria a consumir os dados, assim não faz sentido a aplicação delphi realizar qualquer alteração uma vez que mais cedo ou mais tarde o novo backup iria substituir os arquivos alterado pelo delphi.

Não dá para manter os dois sistema Clipper e Delphi sem possuir os fontes de ambos para saber como estão a tratar o DBF.


Os DBF estão corretos sem qualquer erro, cá consigo lê-os usando o delphi 6 sem problemas.
_________________
Tudo podemos quando tudo sabemos!

[johnny-walker]

Não tenho como ler, pois não tenho mais o delphi 7 instalado, também o windows 10 não permite o database desktop funcionar. Engraçado que no Windows 7 funciona bem, mas no 10 não.


Somente sei que a cada dia está mais difícil de manter softwares legados e manter-se atualizado com os mais recentes sistemas operacionais, pois estão matando este legado, inclusive aplicações 16 bits que estão a cada dia com seu ciclo de vida contados.



bye
_________________
P.O.W.E.R B.Y D.E.L.P.H.I

[profase]

Muito agradecido pela atenção de vcs
Vou elaborar uma resposta mais completa em seguida, mas por enquanto vou satisfazer algumas dúvidas.

Voces não estão conseguindo abrir a tabela pois ela está criptografada pelo Apollo e/ou SixNSX. Para abrir o projeto no Delphi, vcs precisam ter o Apollo instalado no Delphi. Por isso mandei o fonte mais para análise.

Retorno em breve com mais instruções.

Agradecido antecipadamente,

Paulo Ricardo Martinez.

[profase]

Muito Agradecido por compartilharem suas experiencias...Nao está sendo em vão.

A demora da resposta foi o tempo de elabora-la e trabalhar ao mesmo tempo....

A Idéia é de encerrar o uso do clipper, mas ate lá, quando for substituido pelo novo, os dois tem que
caminhar juntos....
Concordo com todos vcs no ponto de vista que ja deveria ter sido convertido ha muito tempo, mas chegou agora
a nossa hora.Estamos sob pressao? sim, pois o esperado de nos é que funcione e funcione bem e pra ontem.
Deixamos de adquirir alguns novos clientes, pelo simples fato de ser DOS. Apesar de estar atualizado e atender a todas
as demandas de mercado, é DOS.

Nosso sistema de gestao é muito grande...incorpora todos os setores, comercial, fincanceiro, compras, producao, etc....
Temos que escrever os dois codigos juntos. DOS atualizacoes, WINDOWS criacoes e novidades...ate que um dia 100% WINDOWS.
Calculamos que vais levar mais 12 meses pro fim deste empreendimento.

como descobrimos o erro:
Implantamos em alguns clientes, uma pequena parte da nova versao WINDOWS ja desenvolvida justamente pra testar
em campo.Junto com a aplicação DOS. Foram duas Rotinas de Manutencao de dados como Cadastro de CLientes e de Produtos....
Funciona bem mas em certos momentos....snif...

O interessante é que o problema nao acontece de imediato. Sabe aqueles problemas intermitentes?
Tem que ser este ambiente, clipper+six , que é o nosso carro chefe. Usamos isso há muito tempo.
sem problemas. Vivemos de um sistema de gestao em DOS escrito em clipper + six que recentemente
estamos convertendo para windows usando o delphi + apolloDB que tem as caracteristicas de
usar a mesma criptografia nos DBFs e as mesmas TAGs nos NSX da SIX , e sem contar que a sintaxe
do apolloDB é xBase,SQL,Client/Server e mais.., tudo ficou mais facil na conversao....
Fazendo pequenas adaptacoes, é como se fosse copiar e colar a programação.

O mais importante, é que o sistema clipper+six que está em uso atualmente, sempre sofre alteracoes
no codigo fonte, SAT,TEF,NFE,etc...
precisam conviver juntos em harmonia ate o desfecho final que será 100% Windows.

nao conheço o harbour, mas ouvi falar muito bem....vou conhece-lo.
como disse nao sei nada de harbour!
Tive decepcoes com clip4win,fivewin...na época desisti de um novo...fiquei só no clipper ate o ano passado....aí, conheci o apolloDB.
Delphi + ApolloDB, realmente é muito bom e atende a todas as nossas nescessidades.

Mudar de ambiente? nao sei.... teria que alterar e muito o codigo fonte em clipper pra aceitar outro RDD do que o sixnsx.....
alem da criptografia....
o detalhe tem que abrir os mesmos dbf+nsx pelo clipper+six e pelo delphi+apollodb
pois uso criptografia.praticamente obrigado o uso do sixnsx. como disse, teria que alterar o code clipper demasiadamente....

Uso Delphi 10.0 e apolloDB 9.0 de ultima geracao....Pelo menos é o que diz ApolloDB ser totalmente compativel..NTX NSX CDX e outros..
clipper 5.2e e Six 3.02(ultima e muito estavel) usamos a mais de 15 anos...

O Sistema funciona muito bem, ate que em um momento, da o problema...
As vezes de imediato, as vezes nem acontece, passa dias sem o problema...

Outro motivo pra nao mudar de ambiente, Ja tem muito codigo escrito. Em torno de 12 meses. E´muito codigo.

Voltando ao problema:

Todos DBF sem campo memo...
Uso Criptografia. por isso indispensavel o SIXNSX, alem do que é rapido....

No apollo os índices podem usar funções, igualzinho no clipper... usa sintaxe xBase
Identico nos dois ambientes.

O erro nao acontece somente em LAN!
Acontece tambem mesmo em duas ou mais janelas da mesma aplicacao WINDOWS no desktop,
compartilhando as mesmas bases de dados.

Nao tenho certeza se o drive SixNsx DOS pode estar causando o problema,
pois se rodar somente aplicaoes windows Delphi+apolloDB. tambem acontece o mesmo erro.

O ERRO acontece em todos estes OS....
win XP,7,10
server 2003,2008,2012

Estamos aguardando retorno da ApolloDB sobre o assunto....assim que tiver retorno terei imenso prazer em
participar a todos....pois esta sendo um desafio muito grande.

Pra quem nao viu ainda,
Este arquivo: www.profase.com.br/ftp/ERROR_1010_1012_Portugues.zip
contem um video explicativo do problema com simulacoes reais.
alem do projeto em delphi, todos os arqs executaveis das aplicoes DOS e WIN + dlls. pra testar.
Se alguem se interesar pelo assunto favor testar em mais de uma aplicacao(DOS e WINDOWS) aberta simultaneamente..
so assim acontece o erro...

Sei que esse assunto é massante, mas tem que ser desse jeito....Compartilhando experiencias....

Retorno em breve.

Muito obrigado,

Paulo Ricardo Martinez.

[profase]

Boa tarde amigos.

Obtivemos um retorno da Apollo e vamos fazer uns testes seguindo as recomendações que são resumidamente as seguintes:

Utilizar as aplicações em Windows no modo Client/Server, deixando o Apollo Server gerenciar o acesso aos DBFs e não o aplicativo client através da LAN.

Retornaremos em breve

Att: Paulo Ricardo Martinez

[profase]

Bom dia a todos,

ENCONTRAMOS A SOLUCAO:
Utilizaremos CLIENTE/SERVER TCP-IP.
Nosso sistema esta rodando a 2 dias, em campo, e nenhum problema de corrupção foi comunicado.

No suporte da APOLLODB, obtivemos o seguinte, traduzido pelo googletradutor:

Usando regras de classificação do DOS vs. regras de classificação do Windows:

Esta é a solução # 1 para corrigir problemas relacionados a índices corrompidos ou dados correntes.

Apollo suporta regras de classificação do DOS e do Windows
DOS e Windows têm regras diferentes para classificar caracteres e, portanto, afetam a forma como o Apollo cria e mantém índices. O problema mais comum que os novos usuários do Apollo experimentam é que eles, inconscientemente, abrem um arquivo DBF e um índice que foi criado usando as regras de classificação do DOS e os dados não parecem ser ordenados corretamente. Na verdade, não é o caso. O que realmente está acontecendo é que o Apollo deve ser informado para usar as regras de classificação do DOS (também conhecido como Machine Collation) em vez das regras de classificação padrão do Windows, para gerenciar esses tipos de arquivos. Isso também é necessário se o seu aplicativo Apollo precisar ser executado simultaneamente com um aplicativo CA-Clipper que compartilha os mesmos arquivos de dados. Para usar as regras de classificação do DOS, você deve informar ao Apollo que use o agrupamento da máquina (ou seja, regras de classificação do DOS).

O problema de "dados corruptos" torna-se aparente quando parece que os dados em um DBF não estão sendo atualizados corretamente de seu aplicativo Apollo ou do aplicativo CA-Clipper. A questão é causada porque o Apollo, por padrão, está usando as regras de classificação do Windows para atualizar os índices, quando ele deveria, de fato, estar usando regras de classificação do DOS. Esta configuração incorreta faz com que o Apollo corrompa os índices, o que faz com que os dados aparecem fora de ordem, sejam inválidos ou simplesmente não apareçam. Se você estiver nessa situação, o remédio é configurar o Apollo para usar as regras de indexação DOS e reindex todos os índices.

Instruções
Consulte os arquivos de ajuda do Apollo e procure "OEMCollation" e "order order". Basicamente, você deve fazer o seguinte:

Ligue para "SDEEngine.SetMachineCollation" no início do seu aplicativo Apollo ou antes de abrir qualquer arquivo DBF.
Especial para usuários do Delphi / C ++ Builder:

Adicione ApoEngInt à sua seção "usa" uma vez que a unidade ApoEngInt contém o objeto SDEEngine
Ligue para "SDEEngine.SetMachineCollation" no início do seu aplicativo Apollo ou antes de abrir qualquer arquivo DBF
Defina OEMTranslate = True para cada objeto de tabela.
Defina OptimisticBuffering = False para cada tabela.
Nota: Esta configuração False deve ser usada se a estrutura / esquema do DBF tiver sido alterado

========================================================================
Acesso compartilhado de dados de rede

Introdução ao Modo Servidor de Arquivo

Os aplicativos que usam o Apollo Embedded podem acessar dados em unidades de rede compartilhadas (por exemplo, F: \ MyDatabase.DBF) no modo de usuário único e simultaneamente enquanto outros usuários acessam o mesmo banco de dados. Este tipo de acesso a dados é muitas vezes referido como "modo de servidor de arquivos". O bloqueio de tabela e registro é gerenciado automaticamente pelas instruções Apollo para SQL e os desenvolvedores que usam a tecnologia DDA da Apollo podem gerenciar bloqueios de tabela e registro manualmente. De qualquer forma, os dados podem ser compartilhados simultaneamente entre vários usuários.

Em um cenário de rede compartilhada, cada estação de trabalho do Windows requer muitos recursos extras para gerenciar o compartilhamento do arquivo do banco de dados ou qualquer arquivo para esse assunto. Nesse caso, um aplicativo incorporado da Apollo não está no controle completo do banco de dados .DBF. De fato, cada aplicativo executado em cada estação de trabalho do Windows abre todo o banco de dados .DBF pela LAN, potencialmente causando grande quantidade de tráfego de rede.

Acesso exclusivo e compartilhado
O ponto chave para entender é o seguinte: O primeiro usuário que acessa o banco de dados .DBF na unidade compartilhada terá um desempenho muito bom em relação ao acesso local da área de trabalho. Sua estação de trabalho do Windows reconhece que ele é o único usuário desse arquivo e, portanto, o Windows é capaz de abrir o banco de dados .DBF em um tipo de modo exclusivo (as configurações do modo aberto do Apollo não afetam essa configuração do Windows. Isso é interno ao Windows trabalho.) . No entanto, no momento em que um segundo usuário acessa o mesmo banco de dados .DBF, o Windows descarta seu acesso ao arquivo de modo exclusivo para um acesso ao arquivo de modo compartilhado, que é uma magnitude mais lenta.

Problema
O ponto crucial do problema é que, mesmo após o segundo usuário fechar sua conexão com o banco de dados, e o primeiro usuário voltou a ser o único usuário que trabalha no banco de dados, a estação de trabalho do Windows dos primeiros usuários não retoma o acesso ao arquivo de modo exclusivo até o arquivo (Ou seja, banco de dados) é fechado e reaberto. Esta é a razão pela qual todos os aplicativos de desktop que executam esse tipo de "servidor de arquivos" sofrem de desempenho multiusuário e porque as aplicações de banco de dados, especialmente, sofrem corrupção de dados e vários outros problemas de bloqueio. Qualquer desenvolvedor Jet / Access de longa data irá reconhecer esse cenário.

Solução
A solução é simples. Para aplicativos multiusuários onde mais de um usuário precisa acessar um banco de dados simultaneamente quando outros acessam o mesmo banco de dados, uma configuração incorporada geralmente não será a melhor escolha. O Apollo Server ignora os problemas do arquivo de rede compartilhado do Windows, permitindo que as aplicações Apollo se conectem a bancos de dados usando o TCP / IP de alta velocidade. O Apollo Server é um aplicativo que é executado no computador que hospeda os dados e escuta em uma porta para aplicativos da Apollo para enviar ou solicitar dados via comandos SQL. Esta é uma verdadeira configuração cliente / servidor e é a melhor solução para o acesso a banco de dados multi-usuário. Além disso, os arquivos de banco de dados Apollo DBF nunca são transmitidos para cada estação de trabalho para processamento,

O Servidor Apollo oferece um desempenho superior que muitas vezes é magnitude mais rápido do que configurações embutidas semelhantes e elimina o excesso de tráfego de rede, garante um alto grau de integridade de dados e mantém os dados seguros.

================================================================================

Acho que isto poe um fim no assunto!

Muito agradecido pela atenção dos amigos.

Abraços,

Paulo Ricardo Martinez.

[johnny-walker]

Que bom que resolveu amigo, visto que poucos utilizam dbf hoje em dia.
Mas eu aconselho a migrar os dados para um banco mais robusto futuramente, pois seria melhor e poderia ter muito mais recursos do banco que este não possui, pois é um banco orientado a textos.



bye
_________________
P.O.W.E.R B.Y D.E.L.P.H.I