Limites dos DBFs em Harbour.

[Mario Mesquita]

Bom dia, pessoal.

Conversando com um colega que usa Visual Fox, me alertou que o limite físico das tabelas DBF é 2GB.

Isso se aplica ao Harbour? Ou é só limite do Fox?

Quem puder dar uma opinião, agradeço desde já.

Saudações,
Mario.

[JoséQuintas]

SISTEMA OPERACIONAL 32 bits limita o tamanho do arquivo a 2GB ou 4GB, não lembro agora.
Esse limite é do sistema operacional.

[Itamar M. Lins Jr.]

Ola!

Código: Selecionar todos

Harbour File Size Limits

    Max record size: 2^16-1 = 65535 byts ( 64 MB )
    Max number of recors : 2^32-1 = 4,294,967,295 ( 4 Bilion )
    Max .dbf file size : 2^48 = 256 TB
    Max DBT memo file size : 2 TB
    Max FPT memo file size : 256 GB
    Max SMT memo file size : 128 GB
    Max NTX file size (standard) : 4GB
    Max NTX file size (incresead ) : 4TB
    Max CDX file size : 4GB

Outros dados, limite do PRG por exemplo, e tipos de dados que não tem no clipper nem no foxpro.

Código: Selecionar todos

In case of numeric values it's the same as in Clipper and
most of other languages - on platforms you are using it's
limited by IEEE758 double value specification.

The date ranges and internal representation is the same as
in Clipper too. In conversions between strings and date values
Harbour supports years in range 0-9999 but Clipper 1-2999.

Harbour has four data types unsupported by Clipper:
   HASH ARRAYS
   TIMESTAMPS
   SYMBOLS
   POINTERS

HASH ARRAYS are arrays which can be indexed by user defined values
of different types (numbers, dates, timestamps, strings, pointers)
For more information read "HASH ARRAYS" in doc/xhb-diff.txt.

TIMESTAMPS are datetime values which contain date and time in
milliseconds (see "DATETIME/TIMESTAMP VALUES" in doc/xhb-diff.txt)

SYMBOLS are references to functions (procedures) or methods.
(see SYMBOL ITEMS AND FUNCTION REFERENCES in doc/xhb-diff.txt)

POINTER items are defined by some subsystems and 3-rd party code
at C level and usually they refers to some low level resources
or memory addresses. In short words it's type of handle returned
to PRG level. Unlike numeric handles pointer item value is protected
and cannot be changed by PRG code so they are much safer. In C code
using pointer items it's possible to verify if given pointer item was
defined by the same subsystem and protect against wrong pointers.
Finally C code author can bound with pointer item destructor which is
executed automatically when variable is out of scope and can release
resources allocated for given item.

Maximum size of strings and arrays is limited only by available memory
(I will use "unlimited" in such case).

Maximum number of symbols in single module (compiled PRG file) is 65536.
Maximum number of symbols registered in HVM from all modules and RDD
subsystems is 65536.
The maximum number of symbols reduces number of different names which
can be used for function/procedure/alias/field/public/private/class/method
names. All such names are registered in HVM in single global symbol table.
Anyhow the maximum size of global symbol table does not mean that it
sets limit for maximum number of given constructions. Some of them like
private variables can share the same name.

There is no limit for number of memvars (public and private variables)
and fields but please remember about maximum size of global symbol table
and number of symbols in single module.
Maximum number of workareas is 65534.
Maximum number of local variables in a single function is 32767.
Maximum number of local parameters in a single function is 32767.
Maximum number of static variables in single module is 65535
(in whole application is unlimited).

The maximum size of literal string defined in PRG code is 16MB.
The maximum size of literal array defined in PRG code is 65535.

The size of PCODE generated for single function is unlimited.
Anyhow maximum size of conditional and unconditional jump in
Harbour is 8388607. It may introduce limits in some construction
so we can only define minimum fully supported size of PCODE generated
for single function or code block as 8MB. Longer code can be generated
if it does not exploit jump size limit.
Macro compiler has exactly the same limits as compiler. For more
info look at section "MACRO COMPILER" in doc/xhb-diff.txt.

Things like maximum number of open files, maximum file size, etc.
are limited only by operating system and used data structures.
Harbour does not introduce any new limits here.
You may find my messages about limits defined by DBF* structures
or read about them in doc/xhb-diff.txt, section "NATIVE RDDs"

best regards,
Przemek 

Saudações,
Itamar M. Lins Jr.

[Mario Mesquita]

Bom dia a todos.

Itamar e Quintas, obrigado por me dar uma luz.

Itamar, então o limite são 4 bilhões de registros? Para um uso em sistemas de pequeno e médio porte dá e sobra por uns 100 anos...

Mas isso se aplica a ambientes 32 e 64 ou tem diferença?

Ainda uso 32 por ainda tenho coisas rodando em Clipper, mas assim que trocar tudo pra Harbour, quero partir pro 64.

Novamente, obrigado pelo auxílio.

Saudações,
Mario.

[Itamar M. Lins Jr.]

Ola!

Mas isso se aplica a ambientes 32 e 64 ou tem diferença?

Tem diferença usando o Harbour em ambiente 64bits, aumenta ainda mais o tamanho. Mas continua sendo questões relacionadas ao SO.(sistema Operacional e suas tabelas), não exatamente limite impostos pelo Harbour.


Saudações,
Itamar M. Lins Jr.

[Mario Mesquita]

Olá!

Itamar, entendi. Interessante mesmo. Como disse, para aplicações pequenas e médias é bem razoável.

Acima disso, melhor usar SQL, não?

Agradeço a dica.

Saudações,
Mario.

[Itamar M. Lins Jr.]

Ola!
Mais uma vez, isso depende de como será feito o sistema.
Existem sistemas enormes usando DBF ou com ADS(SAP-http://www.renet.com.br/solucoes/sap/sa ... server-12/) ou com Caché RDD(http://www.intersystems.com/br/produtos ... -overview/)
Eu nem sei mais qual é o melhor, o DBF tem os prós e contras, SQL dependendo do MOTOR (MySQL/Firebird...) cada qual tem os seus prós e contras...
Se domina o SQL, é bom não inventar e vice-versa para o DBF pois não li ainda ninguém decepcionado usando o DBF com LINUX por exemplo.
O problema é quando mapeamos o DBF...Porém usando o TS(Terminal Service) ou usando NetIO ou LetoDb, não tem mais o problema de dados corrompidos.
SQL é bom pois é mais fácil achar pessoas que sabem usar. O DBF está ficando ou já é uma coisa meio "excêntrica" vamos dizer assim.

Saudações,
Itamar M. Lins Jr.

[Mario Mesquita]

Boa tarde.

Itamar, verdade. Não tenho pratica alguma com SQL, apenas teoria. Talvez para o ano eu comece algo pois considero importante. Pegando confiança, migrar para ele é uma possibilidade. Embora com DBF eu nunca perdi nada.

Acompanho seus posts sobre o LetoDb e achei muito interessante. Para o tamanho das minhas tabelas, deve fazer com o pé nas costas.

Sds,
Mario.