PC Toledo

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.

1) NUNCA USEI COMMIT, é uma possibilidade do problema

2) O arquivo tem campo memo? é uma possibilidade do problema, e só vai ser resolvido se trocar o campo memo pra campo caractere.

Tem que ser SIXNSX? Não pode ser SIXCDX?
No Delphi tem que ser apollo que usa estilo DBF, não pode ser ADS + ADO + comando SQL?
Apollo é pago, ADS é free pra uso local sem servidor.

Fazia a mesma coisa com Visual Basic 6, ADS Local e ADO, usando SIXCDX no Clipper.
Sou de São Paulo também, mas não mexo com Delphi.

Recapitulando o que eu faria:

1. Confirmar as configurações do Windows, recomendadas para DBF.
Tem um fonte no Harbour pra fazer as mudanças.
2. Acabar com TODOS os campos MEMO
3. Eliminar o uso de COMMIT. Melhor SKIP 0, UNLOCK

Se as anteriores não resolverem:

4. SIXCDX e ADS

Fora essas opções, nenhuma outra idéia no momento

Mais uma:
Qual é o servidor? Novell?
Tem bug quando o servidor fica mais de uma semana sem desligar.
Um forma de contornar é uma reindexação copiando os arquivos para novos arquivos.
Com isso, a "tabela de referência" da Novell acaba sendo substituída.

Não mexo com estas coisas há muito tempo, mas lembro bem dos problemas:

1) SIXCDX: Já tive problemas com campo memo, índice corrompido mesmo após acabar de ser criado, e o índice nem fazia referência ao campo memo, apenas porque o campo memo existia. INDEX ON.... SEEK... internal error 1010 (não lembro o número exato do erro).

2) Novell: Ela se perde no tamanho do arquivo. Supondo que o DBF tenha 100 registros, o Clipper considera 101, e no APPEND tenta incluir o 102, e gera erro

3) Windows: A Microsoft inventou o "off-line", neste caso só tive problemas pelo aplicativo não "enxergar" arquivos novos.

4) problemas com Windows 95/95OSR2, 98/98OSR2, uma das versões de cada um vinha com um problema parecido ao da Novell, de retornar tamanho de arquivo errado

5) Misturar XP e Windows 2000. Ao usar um notebook com Windows 2000 acusava erro nos outros terminais, tornando os índices corrompidos.

6) Windows Server: Leve diferença entre PRN e PRN:, se o aplicativo estivesse em uma pasta com nome não compatível com DOS. "minha pasta" por exemplo

E aproveitando, sobre o campo memo: pode confirmar nas estruturas dos meus arquivos: campo MEMO NUNCA MAIS
Foi depois de um problema justamente com a SIXCDX.

https://github.com/JoseQuintas/JoseQuin ... atedbf.prg

Sério isso, no arquivo de pedidos, aonde a observação do pedido era campo memo.

Código: Selecionar todos

INDEX on NumPedido TO temp
SEEK "100"

Não lembro se era erro 1010, ou erro 4421, só lembro que deu erro numa sequência igual à acima.
Foi a única possibilidade que pensei, e realmente um chute certeiro: alterei a observação de campo memo pra caractere 250.
Desde então, nunca mais usei campo memo.

A estrutura mudou muito de lá pra cá, pode ver nesse mesmo fonte; o JPPEDI, a observação é caractere 200.

Apenas novas aberturas de aplicativos são afetadas ... também não há necessidade de indexar ou reindexar os arquivos NSX ....
Não há corrupção de dados ...

No caso do ADS, ele deixava todos os arquivos "presos", como se estivessem abertos, apenas isso.
Se o aplicativo com ADS estivesse aberto, o DBF não poderia ser aberto de modo exclusivo no Clipper.
Até aí, nenhum problema, o único local exclusivo seria numa reindexação, todo restante era compartilhado.
Mas meu uso em VB era totalmente por comandos SQL, já deixando pronto pra qualquer base de dados.

Ola!
O problema é o drive para DOS do SIX. Enquanto usar CLIPPER vai ter esses problemas porque o CLIPPER é para DOS e o SIX do CLIPPER não entende as novas formas de abrir/fechar/travar o registro do DBF no WINDOWS que neste caso VC usa APOLLO que é diferente do SIX.

Opção 1) Na aplicação para DOS use o Harbour + ADS e na aplicação para windows use o Delphi + ADS.
Vai sair mais barato se já tem muita coisa pronta ou
Opção 2) Tudo Harbour com outras possibilidades, isso por causa do seu legado CLIPPER. Pode fazer as mesmas telas do DELPHI via Minigui/Hwgui etc no Harbour e pode depois mudar tudo para SQL que seus usuários nem vão saber.
Com os desenvolvedores que sabem usar clipper, sugiro ensinar a usar o Harbour, a curva de aprendizado quase zero no modo console.

Código: Selecionar todos

/* LOCK SCHEMES */
/* LOCK SCHEMES: RDDI_LOCKSCHEME, DBI_LOCKSCHEME */
#define DB_DBFLOCK_DEFAULT      0
#define DB_DBFLOCK_CLIPPER      1   /* default Cl*pper locking scheme */
#define DB_DBFLOCK_COMIX        2   /* COMIX and CL53 DBFCDX hyper locking scheme */
#define DB_DBFLOCK_VFP          3   /* [V]FP, CL52 DBFCDX, SIx3 SIXCDX, CDXLOCK.OBJ */
#define DB_DBFLOCK_HB32         4   /* Harbour hyper locking scheme for 32-bit file API */
#define DB_DBFLOCK_HB64         5   /* Harbour hyper locking scheme for 64-bit file API */
#define DB_DBFLOCK_CLIPPER2     6   /* extended Cl*pper locking scheme NTXLOCK2.OBJ */

Estas são as possibilidades de uso de um DBF(travamentos) em Harbour, ele convive pacificamente com Clipper, COMIX, VFP, SIX.
Teste para ver o HARBOUR+SIX = (DOS+SIX) com Delphi+APOLO. Basta baixar o Harbour ajustar para SIX=RDDSetDefault("DBFSIX") e testar com sua aplicação Delphi+ApoloDb. Só vai adicionar duas ou três linhas ai no seu PRG para testar.

Código: Selecionar todos

In Harbour it's DB_DBFLOCK_CLIPPER2.


CL52 DBFCDX, SIX3 SIXCDX, SIX3 SIXNSX, [V]FP CDX
================================================
all locks are exclusive (*)
when there is no structural index:
DBF HEADER LOCK: @0x40000000 : 1
DBF RECORD LOCK: @0x40000000 + record offset : 1 (some implementations
                                                  locks whole record)
DBF FLOCK SIZE:  0x3ffffffd
   => maximum file size: 1'073'741'823

when structural index is open:
DBF HEADER LOCK: @0x7ffffffe : 1
DBF RECORD LOCK: @0x7ffffffe - recNO : 1
DBF FLOCK SIZE:  0x07ffffff
   => maximum records: 134'217'727
      maximum file size in non POSIX systems: 2'013'265'919

index file locking is the same for production and normal indexes:
CDX READ LOCK:   @0x7ffffffe : 1
CDX WRITE LOCK:  @0x7ffffffe : 1

In Harbour it's DB_DBFLOCK_VFP.


CL53 DBFCDX, COMIX (hyper locking)
==================================
all locks are exclusive (*), in index shared locks are emulated

DBF HEADER LOCK: @1000000000 : 1
DBF RECORD LOCK: @1000000000 + recNO : 1
DBF FLOCK SIZE:  1000000000
   => maximum records: 1'000'000'000
      maximum file size in non POSIX systems: 1'000'000'000

CDX READ LOCK:   @0xffff0000 + random value from 0x0 to 0xffff : 1
CDX WRITE LOCK:  @0xfffeffff : 0x10001
    if fail then @0xfffeffff : 1
    prepare the index modification in memory and before writing to
    index file lock @0xffff0000 : 0x10000
  to eliminate starvation effect caused by many readers
  on each 16-th read lock reading process tries to lock write
  area @0xfffeffff : 1 instead and then sets normal read lock

In Harbour it's DB_DBFLOCK_COMIX.


Harbour 32-bit locking
======================
all locks are exclusive (*), in index shared locks are emulated

DBF HEADER LOCK: @4000000000 : 1 (exclusive)
DBF RECORD LOCK: @4000000000 + recNO : 1 (exclusive)
DBF FLOCK SIZE:  294967295
   => maximum records: 294'967'295
      maximum file size in non POSIX systems: 4'000'000'000

CDX READ LOCK:   @0xffff0000 + random value from 0x0 to 0xffff : 1
CDX WRITE LOCK:  @0xfffeffff : 0x10001
    if fail then @0xfffeffff : 1
    prepare the index modification in memory and before writing to
    index file lock @0xffff0000 : 0x10000
  to eliminate starvation effect caused by many readers
  on each 16-th read lock reading process tries to lock write
  area @0xfffeffff : 1 instead and then sets normal read lock

In Harbour it's DB_DBFLOCK_HB32.


Harbour 64-bit locking
======================
all locks are exclusive (*), in index shared locks are emulated

DBF HEADER LOCK: @0x7fffffff00000001 : 1
DBF RECORD LOCK: @0x7fffffff00000001 + recNO : 1
DBF FLOCK SIZE:  0xfffffffeUL
   => maximum records: 4'294'967'294
      maximum file size: no limits created by locks

CDX READ LOCK:   @0x7fffffff00000000 + random value from 0x1 to 0xffff : 1
CDX WRITE LOCK:  @0x7fffffff00000000 : 0x10001
    if fail then @0x7fffffff00000000 : 1
    prepare the index modification in memory and before writing to
    index file lock @0x7fffffff00000001 : 0x10000
  to eliminate starvation effect caused by many readers
  on each 16-th read lock reading process tries to lock write
  area @0x7fffffff00000000 : 1 instead and then sets normal read lock

In Harbour it's DB_DBFLOCK_HB64.

https://github.com/vszakats/harbour-cor ... /locks.txt

Saudações,
Itamar M. Lins Jr.

Discordo no seguinte ponto:
Com ADS funciona !!

Mas deve ser levado em conta que o limite do Clipper é diferente do limite do Windows.
O Clipper é da época em a capacidade dos HDs era menor, então tinha limites não testados na época.
Pode ser que pra Windows tenham ampliado a capacidade, apesar que Apollo acho que nunca sofreu atualização.
Teoricamente deveria funcionar muito bem com SIX Apollo, já que se trata da mesma empresa que fez para o Clipper.

O ADS por exemplo, não é 100% compatível.
Um índice criado pelo Clipper é atualizado sem problemas no ADS, mas não o contrário.

E tem também outros detalhes: índices pode usar funções. Não significa que estas funções vão estar disponíveis no ambiente Clipper e no ambiente Windows.
Não sei como isso é tratado entre os dois ambientes.
Muitas vezes é melhor usar Substr() nos índices do que Right(), Left(), Pad(), etc. por ser mais "compatível", ou por ter sido previsto.

Vai ter que avaliar a melhor saída.

O Harbour também tem o índice compatível com SIXCDX, então pode ser avaliada também a troca "menos radical" do Clipper pelo Harbour.
Como eu fiz na época:
Comecei usando Harbour com SIXCDX, existente no Harbour, podendo trocar entre Clipper e Harbour a qualquer momento.
Exatamente os mesmos fontes para os dois, pra não ter problema de perder o controle entre versões.
Tratava-se apenas de escolher o compilador, e não de escolher fontes diferentes.
Então, eventualmente fui fazendo testes com Harbour, trocando um pelo outro, e em caso de problema, retornando o Clipper.
Até que troquei de vez.
Na época que comecei os testes, o Harbour não era igual hoje, até mesmo a RDD default era o ADS, porque as próprias do Harbour não estavam 100%.
Acredito que hoje vai ser muito mais tranquilo.
Só de passar de Clipper pra Harbour, já vai esquecer problemas com máquinas 64 bits, então já será vantagem.

Já vi no grupo harbour-users sobre criarem driver em Harbour pra DBFCDX pra ser usado em outra linguagem de programação.
Poderiam verificar isso também, pois talvez pudesse ser usado no Delphi e seria totalmente compatível.

Mas eu ainda faria uma revisão nos fontes Clipper/Delphi pra ver sobre os bloqueios, principalmente no detalhe que mencionei:

Código: Selecionar todos

RLock()
REPLACE ...
SKIP 0
UNLOCK

E esquecer o COMMIT.

E esquecer campo MEMO também.
Muito usuário aqui nunca teve problema com campo memo, mas eu já tive, como já mencionei.
Mas num aplicativo de terceiros, em Harbour e usando campo memo, chegou a acontecer de corromper o arquivo memo, eu ter que trocar por um vazio.
Acho que esse foi o último uso de campo memo que tive contato.

Putz....
Lembrei de uma coisa, mas superficialmente:
Lembro de um tipo de campo VARIFIELD ou algo assim, que fazia uso de campo MEMO pra armazenar os dados.
Se estiverem usando, já eliminem também.
Nem lembro mais se realmente era na SIXCDX...

E por último: SIXCDX era pra Clipper 5.2, no Clipper 5.3 era COMMIX.
Não era mais o mesmo "fabricante".

Caso optem por testar o ADS:
O ADS LOCAL não tem limite teórico, mas existe um "limite de fábrica" que pode ser configurado.
Segundo o suporte, na época, o limite local era apenas pra incentivar o uso do servidor.
NUNCA COMPREI ADS, nem usei pirata, o ADS Local sempre foi grátis, e na época a revenda do Brasil me deu suporte total ao uso dele.
Só me parece que não é mais assim hoje em dia...

Na época que testei, estas eram as strings de conexão:
mas do Apollo, achei péssimo o jeito de usar, e não saiu dos testes iniciais.

Código: Selecionar todos

Function ConnString(Optional ByVal cBanco As String, Optional ByVal cEmpresa As String) As String
Dim cString As String

If Len(cBanco) = 0 Then cBanco = Sistema.BaseDeDados
If Len(cEmpresa) = 0 Then cEmpresa = Sistema.EmpresaCodigo
If Sistema.EmpresaCodigo = "000000" Then cEmpresa = ""

Select Case cBanco
Case "ADSLOCAL"
    cString = "Provider=Advantage.OLEDB.1;" & _
    "Mode=Share Deny None;" & _
    "Show Deleted Records in DBF Tables with Advantage=False;" & _
    "Data Source=" & Sistema.PathDefault & ";Advantage Server Type=ADS_Local_Server;" & _
    "TableType=ADS_CDX;Security Mode=ADS_IGNORERIGHTS;" & _
    "Lock Mode=Compatible;" & _
    "Use NULL values in DBF Tables with Advantage=True;" & _
    "Exclusive=No;Deleted=No;"

Case "SIXCDX"
' Apollo testado mas trava no conexao.close
   cString = "Provider=ApolloOLEDB7.ApolloOLEDB7;" & _
   "Data Source = " & Sistema.PathDefault & "; " & _
   "AccessMethod= amLocal; " & _
   "TableType=ttSXFOX; " & _
    "CommitLevel = clNormal;" & _
   "FetchCount=1;"
'   "ConnectionHost=127.0.0.1;" & _
'   "ConnectionPort=5000;" & _

Case "ACCESSLOCAL"
   cString = "Provider=Microsoft.Jet.OLEDB.4.0;" & _
      "Data Source=" & Sistema.PathDefault & "jpa.mdb;" & _
      "Persist Security Info=False"

Case "SQLSERVER"
   cString = "Provider=SQLOLEDB.1;" & _
      "Integrated Security=SSPI;Persist Security Info=False;" & _
      "Initial Catalog=tabela1;Data Source=SQLJPA;"

Case "XMYSQL"
   cString = "Driver={MySQL ODBC 3.51 Driver};" & _
      "Server=xxxxxr;" & _
      "Option=131072;Stmt=;" & _
      "Database=xxxxx;" & _
      "User ID=xxxxx;" & _
      "Password=xxxxx;"
      '"Compress=true;"

Case "MYSQL"
   cString = "Driver={MySQL ODBC 3.51 Driver};" & _
      "Server=xxxxx;" & _
      "Option=131072;Stmt=;" & _
      "Database=xxxxx;" & _
      "User ID=xxxxx;" & _
      "Password=xxxxx;"
      '"Compress=true;"

'Case "MYSQLLOCAL"
'   cString = "Driver={MySQL ODBC 3.51 Driver};" & _
'      "Server=10.0.0.55;" & _
'      "Option=131072;Stmt=;" & _
'      "Database=xxxxx;" & _
'      "User ID=xxxxx;" & _
'       "Password=xxxxx;" '& _
'      "Compress=true;"

Case "EXCEL"
   cString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & _
      "DrivePathNome.xls" & _
      ";Extended Properties=" & Chr(34) & "Excel 8.0;HDR=Yes;IMEX=1" & Chr(34) & ";"

Case Else
    MsgBox "Tipo de Banco de Dados não definido"

End Select

ConnString = cString
End Function

Ola!
Quintas, tem que encerrar o Clipper. Não é questão de concordar ou discordar. O Clipper não foi feito para rodar no windows, é fato.
A não ser que use emuladores com o programa dele.
O problema é o clipper, o resto é escolha.
Mesmo que por suas dicas ele encontre o problema, ainda assim ele continuará usando o Clipper que não funciona com win10x e 64 etc...
É só substituir o Clipper pelo Harbour. O harbour e o Delphi funcionam com qualquer SQL que ele escolher ou se desejar ficar usando DBF.
Tirar o Clipper e usar Harbour. Mais simples do que ele possa esta imaginando.
Os clientes dele gostam das telas em clipper então no lugar do clipper ele usa Harbour e o leque de opções dele quanto a banco de dados, fica enorme.
Acaba os problemas com sistemas operacionais, vai poder rodar o programa dele simultâneo até com LINUX+Harbour e com Windows+Delphi se desejar etc... da forma que quiser.

Saudações,
Itamar M. Lins Jr.

Sim, mas a questão é Clipper x Delphi, que pode se transformar em Harbour x Delphi.
Converter um aplicativo quando tudo está bem não é a mesma coisa do que converter sob pressão.
Se a coisa está tão feia como foi dito, convém começar pelas opções "obrigatórias".
Também tem o detalhe de incluir novo registro, que no Harbour pode trazer mais problemas do que no Clipper, dependendo de como foi implementada a opção de pegar código novo. ( Lastrec() + 1 ), principalmente pela quantidade de terminais que foi apresentada.

Se fosse eu faria o seguinte, nesta ordem:

1. a errorsys original.No vídeo, tudo indica que trata-se de uma errorsys modificada.
2. Eu usava nos tempos do Clipper, uma rotina de erros externa ao aplicativo.
3. Acabar com COMMIT, usar somente SKIP 0,UNLOCK
4. Acabar com campos MEMO, se ainda existir
Provavelmente a mesma coisa no Delphi.

E verificar se não tem ninguém com um SO diferente na rede, algum W2000 por exemplo.

Só depois disso pensar nas próximas opções.

Aliás... se em Clipper funciona... parece que a questão maior está sendo o aplicativo em Delphi funcionar em conjunto, usando o Apollo.
Dependendo do que tem a mais, seria questão de deixar em segundo plano até o problema ser resolvido, talvez fazendo as rotinas "a mais" em Clipper mesmo.

Uma vez resolvido, aí pensar em Harbour.
Ou se nada disso resolver, talvez Harbour direto, que já deveria estar em uso há muito tempo.... rs
Aliás... outra opção seria Harbour, depois outra base de dados, e depois Delphi sem gambiarras.

Agora resta alguma resposta, pode até ser que já resolveram e a gente está pensando à toa.... rs

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 ser 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 descobrirmos 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....

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 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.
Realmente é bom e atende 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.

Respondendo as pergunta sobre o problema:

nada de "off-line".
Fiz experiencias sem o COMMIT...sempre mesma situação...
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.

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...

Não confunda Harbour com ambiente gráfico.
A grosso modo, Harbour seria um substituto do Clipper, começa fazendo tudo que o Clipper faz, e muito mais.
Dentro desse "muito mais", existem várias bibliotecas gráficas diferentes, cada uma com suas vantagens e desvantagens, mas no geral a maioria exigindo reescrever código.
Acho que a parte importante neste instante seria: substituto do Clipper, 32 bits roda em qualquer Windows, e apesar de não necessário ainda, também pode ser gerado 64 bits.

Implantamos em alguns clientes, uma pequena parte da nova versao WINDOWS ja desenvolvida justamente pra testar

Não sei se isso significa que foi feita pouca coisa em Delphi.
e não sei qual a exigência dos clientes.

Harbour também poderia usar Apollo, mas pode cair no mesmo problema, caso o problema seja na Apollo SIX.
E se for a própria criptografia que estiver causando o problema, por ter diferença entre DOS/Windows?
Por acaso os índices usam campos criptografados?

No momento, seu principal problema é usar a criptografia que obrigatoriamente depende da SIX, isso impede qualquer alternativa simultânea.

Pra deixar de usar criptografia:
Uma opção seria remoteapp, onde tudo roda no servidor e o usuário não teria acesso a pastas, mas oficialmente precisa licença da Microsoft pra cada terminal.
Outra opção de custo alto é um servidor ADS.

Já com Harbour, tem as opções hbnetio e lettodb, que não dependem de acesso direto a pastas, fazem via TCP/IP como se fosse com servidor MySQL - não com a mesma performance - mas já impediria acesso direto por parte do usuário.

Já passei por isso de ter duas versões diferentes, uma DOS e outra Windows, e isso só trás problemas, acabou por matar a versão Windows.

Meu roteiro seria:

- Deixar os fontes sempre compatíveis com Clipper e Harbour, com opção de criptografia ou não
- Assim que ok, adotar Harbour + hbnetio pra eliminar acesso dos terminais as bases

Depois disso, tranquilo pra decidir.

Comentário:
O aplicativo por acaso teria ou vai ter relatório em PDF?
Se tiver, o usuário pode muito bem copiar o PDF e ter todas as informações, sem se preocupar com criptografia.

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

Mas pra isso, vai ter que comprar licenças do Apollo server pra cada local, ou não?

Bom dia Quintas.

Nao conheco nada do harbour....vou conhece-lo. Ja seria um grande passo.

Agradeço mesmo, pela sua atenção no assunto. É seríssimo...
O importante pra nos é o momento. nao temos tempo. tem muito codigo escrito.
assim que terminado bye bye clipper....a partir daí só no ambiente WINDOWS.

Porque as Aplicacoes tem que rodar juntas? DOS e WINDOWS?
Pelo simples fato de ao criar/converter um novo módulo no sitema WINDOWS,
desativa-se imediatamente o mesmo módulo equivalente no sistema DOS.
O ciclo se repete, ate findar o DOS....

Optei pelo Delphi, por questao de mercado... muito disseminado...
E o ApolloDB pela sua sintaxe xBase e sua integração com a SIXNSX no clipper.
Se nao fosse o problema intermitente da corrupçao, tudo estaria as mil maravilhas.

Mas estamos abertos pra novas ideias.

Em relação a criptografia, a ideia é limitar o acesso nao autorizado a esses DBFs.
Sabemos da vulnerabilidade, ate um printscreen burla....
PDF, HTML, XML comuns em nosso sitema....Se o usuario tiver permissao, imprime a informação desejada.
Nao tem como barrar isto, mas sim limitar o acesso nao autorizado a essas bases.

PARECE QUE ACHAMOS A SOLUÇÃO! QUEM TEM BOCA VAI A ROMA!

Enfrentamos uma dificuldade, que pela visao do pessoal da ApolloDB é comum e eles tem
a soluçao.

Fizemos adaptacoes no codigo Windows, e testamos em ambiente Client/Server TCP/IP como orientado.
E aparentemente resolveu o problema de corrupçao...
Antes de nos preciptarmos, pois aqui é um laboratorio, vamos instalar em campo em alguns clientes com
trafego intenso pra vermos a real situação...

Em breve retornarei com os resultados.

Agradecido novamente,

Paulo Ricardo Martinez

PC Toledo

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)

Corrupcao dados DBF 1010/1012 (Clipper+Six)(Delphi+ApolloDB)