Indice temporario com INDEX ON com dados on-line no DBF?

[ANDRIL]

Ola pessoal,

Vendo os topicos anteriores sobre filtragem resolvi mudar meus filtros para indice temporario. Apos usar o

INDEX ON nomedocampo TO nomedoarquivo FOR condicaox

a filtragem ocorre beleza. So que nao fica on-line com os dados do DBF, pois se eu cadastrar um novo cliente em outra maquina que atenda a CONDICAOX na outra maquina que tem o filtro, ele nao aparece.

No SET FILTER ele entraria tambem no browse pois satisfaz a condicao do filtro. Talvez esse problema seja um empecilho para alterarmos de SET FILTER para o INDEX ON.

Quando o sistema tem um DBF e neste sao abertos 2 indices por exemplo na maquina 1, ao abrir o sistema na maquina 2 eles apenas sao abertos com o SET INDEX TO e pronto, os dados estao on-line, pois os indices estao abertos simultaneamente.

Nota que no caso de um indice temporario, a saida do INDEX TO em cada maquina vai para um arquivo.maq, mesmo estes arquivos ficando no diretorio do sistema no servidor eles nao sao atualizados.

Imaginava que uma vez feito o INDEX ON na maquina que estou no momento e se cadastrar um dado em outra este indice temporario seria tambem atualizado.

Alguem sabe como resolver este problema???


Ja fiz teste com SET ESCOPE pois uso a SIX mais gostaria de saber se o problema acima tem solucao


ate+

[Maligno]

Imaginava que uma vez feito o INDEX ON na maquina que estou no momento e se cadastrar um dado em outra este indice temporario seria tambem atualizado.

De forma alguma. O índice, sendo temporário, existe para a instância que o criou.

Alguem sabe como resolver este problema???

Eu nunca uso índice temporário. Até porque, com a SIX, posso perfeitamente utilizar um SET FILTER. Embora a idéia não pareça muito agradável, note que o SET FILTER é lento apenas enquanto o DBF contiver um volume elevado de dados. Mas com SET SCOPE (recurso presente na SIX) você pode, artificialmente, diminuir esse volume e então, aplicar o SET FILTER sem medo, pois a velocidade tende a se multiplicar várias vezes. Nem parece mais o velho (e lento) SET FILTER.

Entretanto, ainda existe a alternativa de adicionar ao índice principal (supondo que você use índice composto, claro) a chave que satisfaça sua necessidade e possa então, substituir o índice temporário. Com a SIX você pode manter várias chaves distintas.

[rochinha]

Amiguinho

Eu entendo indice temporário como algo que crio num dado momento em um terminal com determinada critica e em outro terminal com critica diferente e se usar em dois terminais uma mesma critica o arquivo temporário possui nome diferente.

Ao criar o temporario eu anexo aos indices correntes como sendo o ultimo indice, mudo o foco, incluo os dados e pronto, tudo fica atualizado.

Agora se sua intenção for criar indice condicional, estes devem ser criados numa indexação, abertos junto com os outros indices e pronto.

Na verdade deste os tempos do NTX eu ja não usava indices condicionais, usava SubNTX(coisa fina, merecia o Oscar) e com CDX, Scope() 200% do tempo e Set Filter.

Acho até que esta dobradinha é unanimidade, pois o Scope() agiliza muito o Set Filter.

[ANDRIL]

Ola

Rochinha, eu usava o CDX com clipper52e. Troquei pela DBFNSX (nao sei se é a mesma SIX da SIX3) agora estou testando a SIX3.

O que ocorre que tenho funcoes de filtragem no meu sistema (varios campos) sao usados para a filtragem pq o sistema tem que buscar um perfil de cliente conforme o filtro designado.

O mais chato do SET FILTER TO é na rede. Entao passei a usar o Sx_SetScope() resolveu 50% do problema, a desvantagem no meu caso, é que só posso usar um escopo e o resto fazer com SET FILTER TO, com isso na rede, a performance cai tambem.

Mesmo com o escopo ativado e o SET FILTER TO os poucos dados mostrados ficam com a paginação lenta.

Entao procurei a usar a SIX3 nao pelo fato de ter o Sx_SetScope() mais procurando alternativas, além que o NG esta em inglês e como apenas arranho.... já viu.

Mais achei um COMANDO pouco citado aqui no forum o SUBINDEX que é uma clausula do próprio INDEX ON da SIX3.

Sua função é criar um sub-indice do indice ativo no momento, ou seja, vc pode criar um indice assim:

index on MEUCAMPO to MEUIDX for MINHACONDICAO

Nesta linha ele cria um indice ja com uma determinada condição feita pela clausula FOR.

Agora se dentro deste indice eu quiser fazer:

index on OUTROCAMPO to MEUIDX1 for MINHAOUTRACONDICAO subindex

o indice anterior é mantido e em cima dele é feito o outro indice, assim, repetindo estas operações posso simular o comando SET FILTER porem com dados praticamentes instantaneos na rede.

Veja que no meu caso eu nao tenho como fazer um simples

INDEX on campo TO meuidx FOR minhacondicao.or.minhaoutracondicao.or.minhasoutrascondicoes

mesmo pq na linha de parametros so pode ter 256 caracteres e na montagem da minha string de consulta necessito muito mais que isso.

Bom ainda estou estudando o novo comando, se alguem ja usa e tiver algumas dicas, serao bem-vindas.


Ate+,

[rochinha]

Amiguinho

Eu uso indices que usam sistematica básica que é:

- ordem cronológica
- ordem alfabética
- ordem numérica

Os indices ficam mais enxutos e muito mais facil de usar escopo. Raras vezes uso dois campos ou mais.

Além do que, para diminuir um conjunto de dados sem sacrificar o database uso os indices condicionais, ex:

Caso de CONTAS, onde armazeno o CONTAS A PAGAR e CONTAS A RECEBER, difereciando os registros pelo campo CONTROLE que pode conter P ou R e o campo FLAG onde armazeno o logico .T. para contas quitadas ou .F. para a quitar.

Num mesmo banco de dados possuo 4 conjuntos distintos então.

Meus comandos de indexação ficam parecidos com estes:

Cronologicamente:

Código: Selecionar todos

INDEX ON dtos(areceber) TAG cta01 FOR controle = "P" .and. flag  // A Pagar
INDEX ON dtos(areceber) TAG cta02 FOR controle = "P" .and. !flag // Pagas
INDEX ON dtos(areceber) TAG cta03 FOR controle = "R" .and. flag  // A Receber
INDEX ON dtos(areceber) TAG cta04 FOR controle = "R" .and. !flag // Recebidas

Uso o escopo no campo ARECEBER na tag cta01, cta02 ou qualquer uma.

Depois uso um SET FILTER complexo para o caso de fazer a filtragem de registros baseado em critérios que o usuário escolherá como:

- registros com SITUACAO de PROTESTO
- que ja foram quitados
- que foram quitados com CHEQUE
- cujo repasse de alguns cheques foram para o JOSE DAS COUVES

Então se o limite esta no comando INDEX de uma enxugada no mesmo, use com mais vontade os escopos e afine os SET FILTERS de suas consultas e criticas.

Verifique também se o fato da lentidão não esteja ligada a arquivos relacionados, ou seja, voce mostras filtrados os dados de uma tabela, mas o que é apresentado na tela, possui colunas com campos que trazem conteudo de outras bases cujo vinculo relacionado nao esteja otimizado.

Não adianta voce fazer uma super filtragem de escopo, indice enxuto, etc se um relacionamento esta ligando duas tabelas super pesadas vinculadas por um campo com 200 caracteres, por exemplo.

Eu também pastei pra otimizar meus escopos, hoje não vivo sem eles.