Pontos de Interrogação no meio do arquivo

[AlexandreADC]

Boa tarde pessoal, nosso cliente está tentando gerar o arquivo do SPED Contábil, existem tantas movimentações em 2011 que o arquivo acaba ficando com quase 600.000 linhas e mais que 30Mb...

E quando há um volume assim há algumas anomalias que pelo Debug eu iria demorar anos pra encontrar, pois começam a aparecer depois de 400.000 linhas do arquivo...

Olhe alguns exemplos de linhas que ele gera:

|I250|1220||4714,20|C?||NF: 01672? Com?anh?a Nacional de Abastecimento CONAB||

|I200|?036?2|09112?11|?850,00|?|

|I250|7869||1850,00|D|||CTRC 000776 ? Fe?tipar Fertiliza?tes?do Parana Ltda||

|I250|6820||1850,00|C?||CTRC ?00776 Fertipa? Fertilizantes do Parana Ltda||

|I?00|503693|31102011|3448?6,21|N|

|I250|1220||344866,21|D|||NF: 0031'1 † Co?pan?ia Naci?nal de Abastecimento CONAB||

|I250|1598||3?486?,21|C||?NF: 003?21 Companhia Nacional de Abastecimento CONAB?|

|I200|503694?311?2011|7566,00|N|

|I250|1220||7566,0?|D|||NFl 00?074 ?omp?nhi? Nacional de Abastecimento CONAB||

|I250|1?98||7566,00|C|||NF: 003074 Companhia Nacional de Abastecimento CONAB||

como visto acima, raras as vezes ele chega até a ficar no lugar do "2" do I200 (deixando I?00), e em algumas vezes, a mesma String (Companhia Nacional de Abastecimento CONAB), apresenta alguns caracteres especiais no meio, ou não.

Estamos preocupados porque dá mais erros no validador do que poderíamos alterar manualmente no arquivo...

Alguém tem alguma ideia como resolver?

[EMBarbosa]

Qual a versão do Delphi que está usando. Verificou se não é algum erro de Unicode?

Se não for, me parece erro de memória.

Você consegue reproduzir o acontecido em outras máquinas?

Consegue reproduzir algo parecido com o DEMO?

[AlexandreADC]

Só acontece neste cliente que tem esse volume de lançamentos...

Uso o Delphi XE, cada vez que gero o arquivo, ele aparece as interrogações em pontos diferentes... Como falei, debugar uma geração que pode levar horas sem breakpoints, imagina com...

Pode ser sim erro em Unicode, já que a declaração da procedure está function TBloco_I.WriteRegistroI200: AnsiString;

e o LFill está function TACBrTXTClass.LFill(Value: TDateTime; Mask: String = 'ddmmyyyy'): String;

O Delphi fica convertendo automático toda hora e em algum momento deve estar se perdendo... (eu imagino que seja)

Delphi 7 não usa Unicode né?! Podiam colocar lá, algo semelhante ao feito no SPED PIS/COFINS: Diretivas de compilação! hehe

Tanto que dias atrás tive problemas com a tabela de caracteres da mensagem de erro retornada pelos componentes do Sped Fiscal e Contábil que usam ANSI, colocando diretivas lá: {$IFDEF UNICODE} resolveria nossos problemas...

Nem vou querer iniciar discussão sobre o uso do Delphi 7 ou dos posteriores, porque sou teimoso demais pra discutir rsrsrs

Vou modificar aqui o componente colocando no bloco I as diretivas e gerar e verificar...

[EMBarbosa]

Vou modificar aqui o componente colocando no bloco I as diretivas e gerar e verificar...

Isso. Verifique se resolve. Se resolver a gente pode pensar em algo que não atrapalhe o desenvolvimento em outras versões.

[AlexandreADC]

Além de diminuir a geração do arquivo de 4h para 10 minutos, não gerou mais os pontos de interrogação dentro do arquivo...

Fiz em 2 Blocos apenas, mas já deu uma grande diferença pra mim...

Se usassem diretivas como essa em todo ACBr, ia diminuir os milhares de warnings de conversão de ANSI para Unicode...

Está aqui o arquivo: ACBrECDBloco_I_Class.pas

[EMBarbosa]

Eu acho que seu problema seria mesmo nas chamadas do LFILL, RFILL e semelhantes. Elas estão retornando string, mas as variáveis internas dos componentes (strRegistroI200 por exemplo) estão definidas como AnsiString.

Você poderia usar essa diretiva de compilação no arquivo ACBrTXTClass.pas e resolver seu problema para todos os componentes de uma vez só, mudando o retorno delas para AnsiString ao invés de apenas String. O que acha?

[AlexandreADC]

O TStringList foi feito pra Unicode e não pra AnsiString apartir do Delphi 2009*... Ele teria que converter mesmo assim ao adicionar a linha...

E todas as properties texto de todos os Blocos estão como String, então voltaríamos a estaca zero haha

O LFILL, RFILL e semelhantes usam funções dentro dele que trabalham com String também...

Eu acho que se fizer isso vai aumentar ainda mais as conversões implícitas de AnsiString pra String e vice-versa...

[EMBarbosa]

Talvez... Mas se for para habilitar o string em unicode quando estiver definido a diretiva UNICODE igual você fez no seu código, seria melhor declarar as variáveis como string logo de uma vez. Pois se não estiver definido o UNICODE, String já é igual a AnsiString e não há nenhuma necessidade de definir strRegistroI200 como AnsiString...

[AlexandreADC]

Você está certo, visto que o "String" em versões anteriores ao Delphi 2007 são Ansi...

Então por quem fez, qual foi o objetivo de declarar essas variáveis em AnsiString?

[AlexandreADC]

Sei que a maioria usa Delphi 7, mas os que usam Delphi 2009* ~ XE2 não devem ser esquecidos!

[EMBarbosa]

Sei que a maioria usa Delphi 7, mas os que usam Delphi 2007 ~ XE2 não devem ser esquecidos!

Não é que os usuários estão esquecidos. Vários usuários compilam em Delphi 2007 ~ XE2 e não tiveram nenhum problema ainda. Eu mesmo compilo em Delphi XE e não consegui reproduzir esse problema.

Você consegue criar uma aplicação para reproduzir o problema ou reproduzir o problema no DEMO? Assim eu poderia investigar. Não criei o componente para SPED, apenas tenho ajudado a melhorar.

[AlexandreADC]

Vou tentar simular no DEMO... Vou colocar lá uns for até 100000 pra aumentar a quantidade de movimentos...

Como eu falei, vai ser difícil debugar porque o erro dá lá depois de milhares de registros...

O erro não é fixo com um ou outro registro, mas SEMPRE acontece com volumes grandes de dados. Mas não ocorre em todas as linhas, só em dezenas, as vezes centenas de linhas...

E com a mudança que fiz deixou de aparecer os "?" no meio do arquivo.

To esperando o DEMO gerar o arquivo, vai durar algumas horas sem minha alteração :S

[AlexandreADC]

achei uma matéria interessantíssima sobre a perda de desempenho nas conversões implícitas.

http://www.bobswart.nl/weblog/Blog.aspx?RootId=5:3294

E outra, quando compilo o ACBr, sempre vem warnings alertando:

[DCC Warning] ACBrEFDBloco_0_Class.pas(1001): W1058 Implicit string cast with potential data loss from 'string' to 'AnsiString'

Então já é esperado essa perda de dados...

A geração pelo DEMO não criou os "?" no meio do arquivo... Quem saiba por não fazer tanto processamento pesado já que fiz um "for" em vez de pegar os dados de um ClientDataSet...

E quanto ao tipo STRING: http://docwiki.embarcadero.com/RADStudi ... ring_Types

Entendo a necessidade de Usar AnsiString para quem usa Delphi 7, mas o uso no Delphi XE só causa dores de cabeça...

Eu ainda não entendo porque adicionar aquelas diretivas é tão prejudicial ao projeto...

[EMBarbosa]

Entendo a necessidade de Usar AnsiString para quem usa Delphi 7

Toda string de Delphi 7 é AnsiString. Não há necessidade de usar AnsiString em Delphi 7. A necessidade deveria ser para as outras verões. O problema é que eu não tenho nenhum caso para estudar o problema...

[AlexandreADC]

Pelo que disse nosso colega italojjr, String no Delphi 7 é ShortString. Daí sim a necessidade de usar o AnsiString.

[EMBarbosa]

Pelo que disse nosso colega italojjr, String no Delphi 7 é ShortString. Daí sim a necessidade de usar o AnsiString.

Isso foi um equívoco. No Delphi 7 String é AnsiString por default. A menos que você use a diretiva de compilação {$H-} o que torna string em ShortString. ShortString no Delphi 7 é mantido apenas por questão de compatibilidade.

EDIT: Acredito que no Delphi 6 seja o mesmo. Mas no Delphi 7 eu tenho certeza. Acabei de conferir no Help.

[AlexandreADC]

Tudo bem, fiz a alteração do ACBr aqui na minha empresa, mas fica a solução no forum se alguém mais tiver os mesmos problemas que tivemos quando há grande volume de dados.

[Isaque Pinheiro]

Sei que a maioria usa Delphi 7, mas os que usam Delphi 2009* ~ XE2 não devem ser esquecidos!

Mude as variáveis e os retornos dos métodos para STRING, se funcionar mudamos de todos, sem problema.

Fico no aguardo.

[AlexandreADC]

Como eu disse anteriormente, depois que eu troquei para String nos blocos que estavam dando problemas, parou de aparecer caracteres estranhos no meio e melhorou a performance de 4h para 10 minutos da geração do arquivo.

Não troquei em tudo por falta de tempo mesmo...

[Isaque Pinheiro]

Como eu disse anteriormente, depois que eu troquei para String nos blocos que estavam dando problemas, parou de aparecer caracteres estranhos no meio e melhorou a performance de 4h para 10 minutos da geração do arquivo.

Não troquei em tudo por falta de tempo mesmo...

Baixe a atualização do SVN, mudei tudo para String, faça o teste e nos report se funcionou rápido como vc disse, se funcionaou vou aguardar mais um tempo e mudar de todos os SPEDs, obrigado pelo relato.

[AlexandreADC]

Beleeeza cara!

Gerou rapidinho, e sem pontos de interrogação!

Ficou 100%

Muito obrigado Isaque Pinheiro!