PC Toledo

Na prática tudo depende aonde vai usar.
Às vezes uma coisa que agiliza numa determinada parte do aplicativo deixa outra parte mais lenta.
Cada parte poderá ter um tratamento diferente.

Aqui, dependendo do caso, até uso SET ORDER TO 0

Toda essa discussão seria desnecessária se o OrdKeyCount já ignorasse os registros deletados que estão dentro do filtro! Seria tão simples...

Não entendeu a extensão disso.

OrdKeyCount() vai lá na estrutura do arquivo CDX e pega a quantidade.
As funções de CDX trabalham com o CDX somente.

Pra acrescentar a opção de deletados ou não... teria que existir o processamento do DBF.
Isto mistura funções de CDX com funções do DBF.

Mas dá pra usar qualquer RDD, e mixar tudo.
Tem RDD até pra ADO, MySql, etc.

Então, o que parece simples se tornaria um pesadelo, arriscado a erros em tudo.

Se não me engano, a SIX fazia otimização quando existia um índice por Deleted(), assim a parte de CDX só trabalharia dentro do CDX.
Mas imagine um arquivo com milhões de registros, e processar todo o arquivo pra contar 0 registros deletados.
Ou isso embutido automático, e todo mundo ter que esperar esse processamento.

De repente envolve criar índice deletado como opção pra cada índice que existir. E por aí vai.
Será que compensa acrescentar lentidão?

Talvez por isso não exista Deleted() em banco SQL.

Pelo que pude entender, quando um registro eh apagado de um dbf, ele eh marcado como deletado no dbf, mas no cdx continua do mesmo jeito, como se ainda existisse!

Meio confuso isso pq qndo se faz um seek a busca eh feita no indice e um registro q esta deletado no dbf, mas não no indice, retorna falsa essa procura.

Exemplo:

Deleto o registro 300 no dbf. No indice esse registro continua intacto.

DbSeek( 300 ) retorna FALSO nesse caso pq esse registro 'nao existe' no dbf, mas existe no indice. Se seek procura no indice e não no dbf, não deveria retornar verdadeira essa consulta???

Eh negada... so doido mesmo pra entender isso rsrsrsrsrsrs

é.. no caso do SEEK acaba envolvendo deletado, pra pular se estiver SET DELETED ON.

Mas até isso pode causar problemas.
Um teste simples:
Pegue um arquivo o maior que puder.
Delete tudo sem usar o PACK, menos alguns registros no final.
Depois rode este programa simples:
marque o tempo com registros deletados e sem registros deletados.
Vai ver a diferença.
A demora é por estar pulando registros deletados.
Em rede então... parece ter travado tudo...

Melhor ainda....
Depois faça a mesma coisa com tudo deletado, menos o PRIMEIRO registro.
Neste caso o USE continuará instantâneo.
Motivo: não precisa pular nada no use.

Nota: lembrando que local pode ser rápido, mas em rede não. a velocidade do HD + cache é muitas vezes mais rápida do que pela rede, por isso só vai dar pra perceber diferença visível se a quantidade for muitas vezes maior do que pela rede. Por isso o teste local precisa ser com arquivo muito maior.

Nota2:
Antigamente eu pensava assim: se o HD lê 3GB/segundo, e a rede é 100MB, então local é 30 vezes mais rápido que a rede.
Mas não é. Local tem o cache. E pela rede, tem os blocos de comunicação que trafegam pouco. talvez na prática seja 1.000 vezes mais rápido ler um dbf sequencial. E se repetir o teste, vai ser mais rápido na segunda vez, por causa do cache local.
Por isso esse teste tem que ser com milhares de registros se for local, ou talvez 1 milhão.