NTX com FPT no Harbour - Alguém usa?
Enviado: 23 Fev 2017 23:23
Olá, alguém já testou em campo/produção a capacidade do Harbour de utilizar DBFNTX com FPT?
Vi na web e no arquivo C:\hb32\doc\oldnews.txt que o Harbour aceita qualquer combinação de indices (DBFNTX, DBFCDX,...) com qualquer tipo de Memo (DBT, FPT, SMT) e que ele detecta automaticamente o tipo do Memo sendo usado.
Fiz alguns testes usando a função que controla esse recurso, citada no C:\hb32\doc\oldnews.txt:
rddInfo(RDDI_MEMOTYPE,<DB_MEMO_DBT|DB_MEMO_FPT|DB_MEMO_SMT> [,<cRdd>])
Usando o HBRUN (que é o DBU do Harbour) Exportei um arquivo DBFNTX/DBT para DBFNTX/FPT mais ou menos assim:
setmode(25,80)
set century on
use CadCli
RDDInfo(14, 2) // seta o tipo de Memo para FPT, equivale a rddInfo(RDDI_MEMOTYPE, DB_MEMO_FPT), vide C:\hb32\include\dbinfo.ch
copy to CadCliNew // arquivo exportado, com Memo tipo FPT
quit
Depois renomeei CadCliNew.dbt e CadcliNew.fpt para CadCli.dbf e CadCli.fpt
Nos testes preliminares sem mudar a aplicação (que usa DBFNTX padrão), ela abriu normal o CadCli.dbf (e o CadCli.fpt, autodetectando o FPT mesmo estando em DBFNTX), gerou os arquivos de índice .NTX normalmente e permitiu editar e salvar os campos Memo normalmente. O arquivo .FPT ficou muito menor que o antigo .DBT (1/5 do tamanho).
Minha dúvida é se esse recurso de usar DBFNTX com Memos FPT é confiável mesmo, se alguém já usou em campo/produção sem problemas.
Poderiam me perguntar: Por quê já não migrar direto para o DBFCDX/FPT padrão?
Explico: minha aplicação possui alguns controles internos pra compensar as deficiências dos NTX (verificação de existência de todos os índices com reconstrução e reindexação periódica). Como então só necessito das vantagens do FPT (robustês, confiabilidade, eficiência de espaço e maiores limites), pensei em só mudar o Memo para FPT mantendo os índices em NTX, pois não haveria nenhum retrabalho no código (que seria grande), somente simples exportações como citei.
Os arquivos .DBT que temos já estão se aproximando daquele limite perigoso de corrupção (32MB) e por isso pretendo fazer a migração para .FTP em breve.
Agradeço a colaboração.
Vi na web e no arquivo C:\hb32\doc\oldnews.txt que o Harbour aceita qualquer combinação de indices (DBFNTX, DBFCDX,...) com qualquer tipo de Memo (DBT, FPT, SMT) e que ele detecta automaticamente o tipo do Memo sendo usado.
Fiz alguns testes usando a função que controla esse recurso, citada no C:\hb32\doc\oldnews.txt:
rddInfo(RDDI_MEMOTYPE,<DB_MEMO_DBT|DB_MEMO_FPT|DB_MEMO_SMT> [,<cRdd>])
Usando o HBRUN (que é o DBU do Harbour) Exportei um arquivo DBFNTX/DBT para DBFNTX/FPT mais ou menos assim:
setmode(25,80)
set century on
use CadCli
RDDInfo(14, 2) // seta o tipo de Memo para FPT, equivale a rddInfo(RDDI_MEMOTYPE, DB_MEMO_FPT), vide C:\hb32\include\dbinfo.ch
copy to CadCliNew // arquivo exportado, com Memo tipo FPT
quit
Depois renomeei CadCliNew.dbt e CadcliNew.fpt para CadCli.dbf e CadCli.fpt
Nos testes preliminares sem mudar a aplicação (que usa DBFNTX padrão), ela abriu normal o CadCli.dbf (e o CadCli.fpt, autodetectando o FPT mesmo estando em DBFNTX), gerou os arquivos de índice .NTX normalmente e permitiu editar e salvar os campos Memo normalmente. O arquivo .FPT ficou muito menor que o antigo .DBT (1/5 do tamanho).
Minha dúvida é se esse recurso de usar DBFNTX com Memos FPT é confiável mesmo, se alguém já usou em campo/produção sem problemas.
Poderiam me perguntar: Por quê já não migrar direto para o DBFCDX/FPT padrão?
Explico: minha aplicação possui alguns controles internos pra compensar as deficiências dos NTX (verificação de existência de todos os índices com reconstrução e reindexação periódica). Como então só necessito das vantagens do FPT (robustês, confiabilidade, eficiência de espaço e maiores limites), pensei em só mudar o Memo para FPT mantendo os índices em NTX, pois não haveria nenhum retrabalho no código (que seria grande), somente simples exportações como citei.
Os arquivos .DBT que temos já estão se aproximando daquele limite perigoso de corrupção (32MB) e por isso pretendo fazer a migração para .FTP em breve.
Agradeço a colaboração.