PC Toledo

sygecom, filizola e demais amigos do forum

Problema resolvido, mandando zerar a variável depois da impressão como disse o sygecom os totais não estão mais sendo acumulados.

Fico muito gratos a todos vocês.

Porém gostaria de entender onde estou errando na condição abaixo, pois tentei finalizar a condição em vários lugares e sempre não dava nada. Por isso acrescentei @mlinha35 e @mlinha68.

Veja que no exemplo que o Pablo postou essa linha esta dento de uma condição...lhe pergunto essa condição esta sendo executada ? pq se não tiver passando por dentro da condição....ele não vai mostrar o resultado

ela está dentro da condição if, conforme abaixo:

filizola escreveu:amigo, como disse o maligno, crie um indice temporario.

Se o BD for pequeno e indicado para ser criado no "C:" (isto é, na propria estação), até seria aceitável. Mas quanto o arquivo é extremamente grande, acho que essa opção fica demorada, principalmente se o relatório tem que ser feito mais de uma vez por dia. Conveniente seria, ter um índice por data (mas não condicional, como foi indicado), daí o filtro pode ser feito no próprio procedimento do relatório.

O que o colega queria, era adicionar uma linha separando os indivíduos com sub-totais. Mas o exemplo do colega Filizola está também correto.

Faltou re-atribuir sua variável razao :=(NOTA2->nrazao) após imprimir a linha de sub-total (que pula de individuo). Ficando assim:

Ja estava me esquecendo mudei meu fonte para zerar a variável mlinha para ficar certo, estava somando os espaços também.

Mas veja um detalhe Gelson, aconselho você utilizar para imprimir o "?" ou "@" para que fique padronizado. Tem que saber qual é o tamanho em linha da sua folha e também verificar que o valor mlinha não ultrapasse esse valor, é claro.

Pablo,

Vou fazer a mudança que você disse e testar, dando certo deixarei com ?, incialmente defini minha mlinha com o valor de 66.

Quanto so dbf, é tem apenas 2mb, o indice foi criado por (data+nrazao)

Agradeço a todos pela boa vontade em esclarecer minhas muitas duvidas.

Bom. Eu também gosto de usar o "?", pois não tenho que me preocupar com PROW() e essas coisas. É só concatenar a linha toda que vai ser impressa e tchau.

Queria passar mais um conselho (como própria experiência), eu acostumo SEMPRE (salvo pouquíssimos casos) criar arquivo de impressão. Isto me permite não tão somente poder exibir em tela como também de re-imprimir ou re-visualizar o relatório sem a necessidade de RE-PROCESSAR todo o relatório novamente. Além do mais, que criando arquivo de impressão posso imprimir em qualquer impressora (em USB inclusive, com aplicativos externos dos colegas, como do Heveraldo, Maligno e MarcosV). Inclusive a impressão feita através do arquivo_de_impressão, no WINXP é impresso mais rapidamente e em rede isso faz toda uma diferença. Pense nisso.

Mas uma vez venho solicitar aos amigos uma explicação para compreender o fato abaixo:

Quando peço o relatório com data de 01/06/07 a 15/06/07 por exemplo são impressos os dados de 02/06 a 14/06, se peço com data de 31/05/07 a 16/06/07 então são impressos com 01/06 a 15/06. Para resolver o problema dei uma remendada no fonte. Agora esta saindo certo por que internamente ele acrescenta mais um dia na data final e diminui um dia na data incial.


dbgotop()

while !eof()

if ndataem >= mdatfim + 1 .or. ndataem <= mdat_ini - 1

dbskip()
loop
end

Caro Gelson,

1. Se â sua intenção é imprimir de 01/06/07 a 15/06/07, então a sua lógica deveria ser assim:

mdat_ini:=CTOD("01/06/07")
mdat_fim:=CTOD("15/06/07")
if ndataem >= mdat_ini .AND. ndataem <= mdat_fim

Em palavras: a sua data_emissão deve ser maior ou igual que a data_inicial E a sua data_emissão deve ser menor ou igual que a data_fim

2. Se seu caso você está pretendendo imprimir de 02/06/07 a 14/06/07, então a sua lógica deveria ser assim:

mdat_ini:=CTOD("01/06/07")
mdat_fim:=CTOD("15/06/07")
if ndataem > mdat_ini .AND. ndataem < mdat_fim

Em palavras: a sua data_emissão deve ser maior que a data_inicial E a sua data_emissão deve ser menor que a data_fim

3. Se seu caso você está pretendendo imprimir de 02/06/07 a 15/06/07, então a sua lógica deveria ser assim:

mdat_ini:=CTOD("01/06/07")
mdat_fim:=CTOD("15/06/07")
if ndataem > mdat_ini .AND. ndataem <= mdat_fim

Em palavras: a sua data_emissão deve ser maior que a data_inicial E a sua data_emissão deve ser menor ou igual que a data_fim

4. Se seu caso você está pretendendo imprimir de 01/06/07 a 14/06/07, então a sua lógica deveria ser assim:

mdat_ini:=CTOD("01/06/07")
mdat_fim:=CTOD("15/06/07")
if ndataem >= mdat_ini .AND. ndataem < mdat_fim

Em palavras: a sua data_emissão deve ser maior ou igual que a data_inicial E a sua data_emissão deve ser menor que a data_fim

Parece redundante meus exemplos, mas a idéia é ser mais claro possível para você entender. Acho que resumidamente (e deduzivelmente) se maior erro estava que você usava o ".or." em lugar de ".and.", pois com o OR você apenas está permitindo que faça uma sentença OU outra (não as dois). Se ainda ficaram dúvidas, por favor volte a nos dizer que tentarei explicar melhor.

• if ndataem >= mdat_ini .AND. ndataem < mdat_fim
             1ª sentença          E          2ª sentença

Pablo,

Ontem a noite eu tentei várias vezes usando o .and. o problema é que gera relatório todo avacalhado, com dados foram do periodo pedido, aparecem linhas em branco, coisa mais louca.

Tentei de tudo que é jeito até que descobri que usando o .or. as duas condições são executadas, por isso tive de usar este remendo do +1 e -1. Até pensei que poderia ser indice, mas se fosse não deveria ter funcionando com o remendo no fonte. certo ?

Geralmente uso meus indices de data assim:

Eu acho que você deveria dar uma olhadinha no DBF para ver se não gravou uma data erra. Lembre que 07 não quer dizer 2007, dependendo o EPOCH ô sistema irá interpretar como 1907. Ja pensou 20/01/1907 em lugar de 20/01/2007 ?

Outra coisa, eu me asseguraria em colocar o CENTURY ON e fazer digitar com os quatro dígitos e ainda fazer uma função que não permita datas como 1907. Eu postei um exemplo dessa função se quiser (só dizer) que eu posto novamente.

Outra medida que eu tomaria para indexar datas no seu lugar eu indexaria:
index on nrazao+strZERO(year(ndataem),4,0)+strZERO(month(ndataem),2,0)+strZERO(day(ndataem),2,0) to relnf

STRZERO para garantir ZEROS em lugar de espaços para o SEEK é mais eficiente ou então utilize:
index on nrazao+DTOS(ndataem) to relnf que é mais prático e ortodoxo

Faça um teste, mude essa indexação e verifique se irá dar esses resultados malucos que você mencionou.

Ahhh lembrei... muito provável que seu arquivo de índice, possa estar desatualizado. Pode haver falha de atualização do índices. Quando você abre um arquivo DBF num módulo do seu sistema que precise GRAVAR no DBF você abre TODOS seus índices ?. Apague o arquivo e verá.

1) No dbf está correto ano com 4 digitos.

2) nrazao+DTOS(ndataem) to relnf [ erro de sintaxe no “+”] erro c2001.
StrZERO , o clipper também reclama de sintaxe no “+ “


3) O Indice é deletado e criado outro quanto a tela e aberta.


Uso :

SET DATE BRITISH
SET EPOCH TO 1990

.

.
SET CENTURY ON
@10,10 SAY 'INFORME DATA INICIAL:'
@10,34 GET mdat_ini PICTURE '@D'
@13,10 SAY 'INFORME DATA FINAL:'
@13,34 GET mdatfim PICTURE '@D
..
.
.

Porque mesmo usando .or. executa as duas condições ?

Porque usando o +1 e –1 ele mostra as informações corretas ? pedindo para gerar de 01/06/07 a 01/06/07 e acessando o banco pelo dbu, as informações conferem estão certas.

Gelson escreveu:1) No dbf está correto ano com 4 digitos.

Não isso não quer dizer que esteja correto ao menos que você tenha edita o DBF (com DBU, por exemplo) e olhasse as datas se existe datas por exemplo: 20/01/2007. Não sei se você verificou isso mesmo ?

Gelson escreveu:nrazao+DTOS(ndataem) to relnf [ erro de sintaxe no “+”] erro c2001.

O campo nrazao é caracter ?. Mas esse código de erro dá como erro de sintaxe.

Gelson escreveu:Porque mesmo usando .or. executa as duas condições ?

Porque o sistema executa logo apenas atenda a primeira condição. Se a data atendeu a primeira condição faz, senão ele verifica a segunda e se atendeu ele faz senão não faz nada.

gelson, eu ainda não sei extamente a sua necessidade. poderia me indicar dos quatros exemplos que citei qual seria o que você pretende ?.

Desculpe não tinha lido esta sua parte:

e acessando o banco pelo dbu, as informações conferem estão certas.

Tá estranho e deve ter algo errado no seu índice.

O campo nrazao é caracter ?

SIM

eu ainda não sei extamente a sua necessidade. poderia me indicar dos
quatros exemplos que citei qual seria o que você pretende ?.

IFf ndataem >= mdat_ini .AND. ndataem <= mdatfim ( esta aqui onde é pego as datas maiores e iguais a data incial, e menores e iguais das datas finais.

com o +1 e -1 funciona, mas queria entender onde está o problema.

com o +1 e -1 funciona, mas queria entender onde está o problema.

Desculpa insisitir, mas você também esqueceu de mencionar quais são as datas para mdat_ini e mdatfim que o usuário digita e qual é o resultado que você espera. Porque acho muito estranho saber que você deletou o índice, verificou no BD se as datas estas certas... pois não deveria estar dando errado nada. No seu relatório, você exibe as datas ndataem ?