Dailton Menezes

Olá, Desenvolvi um aplicativo Delphi 7 ISAPI para devolver o streamer do PDF dado um ID_CTE buscando o xml armazenado em uma tabela Oracle. Este aplicativo fica na intranet da empresa. Quando tento acionar o método ACBrCTe.Conhecimentos.ImprimirPDF uma exceção é gerada com a mensagem "There is no default printer currently selected" Esta aplicação ISAPI roda num ambiente Windows 2003 sob IIS 6 usando-se Delphi 7 com QR 4.07. Existem impressoras definidas no sistema operacional mas no contexto do IIS não há uma associação de default. O mesmo código usado na aplicação ISAPI em uma aplicação DESKTOP funciona perfeitamente. Portanto o contexto do IIS é que causa o problema. Pergunta: teria uma maneira de contornar este problema ? A nível do componente na criação interna da instância do QR? Observação este ISAPI também devolve o PDF de uma NFE usando o componente ACBrNFeDANFERaveCB e funciona muito bem no mesmo contexto do IIS. Grato

Pessoal, Eu fiz um serviço do tipo ISAPI em Delphi 7 rodando sob IIS 6/W2003 para atender requisições na nossa empresa (intranet) para visualização da DANFE em PDF. O usuário faz uma pesquisa na nossa base de dados de XMS's recebidos de fornecedores e a aplicação devolve o PDF. O serviço é bem simples, recebe o IDNFE e devolve um stream do tipo "application/pdf" usando a unit ACBrNFeDANFERave para gerar o PDF. Tudo funciona bem por um tempo. Depois de um número x de acessos que não determinei, o componente devolve o conteúdo de uma consulta anterior mesmo embora eu tenha passado o XML novo. Gastei um tempão tentando descobrir o que poderia gerar a falha e tomei alguns cuidados na hora do tratamento do request http: 1) Criei uma CriticalSection para evitar dois ou mais requests concorrentes pois a unit ACBrNFeDANFERave poderia não ter sido projetada para ser reentrante. Isso ampliou o tempo de estabilidade da rotina mas mesmo assim voltou a acontecer no transcorrer do tempo 2) Mudei também o programa para, ao invés de devolver o stream como response, passei a gravar o PDF numa área do site e devolver a URL para o PDF gerado tentando evitar alguma interferência de cache do IIS mas mesmo assim o problema persistia. 3) Por último, descobri um fato curioso. Se o componente TACBrNFeDANFERave fosse criado dinamicamente ao invés de ficar fixo no datamodule, o problema ficava aparentemente contornado. Passei então a criar o componente TACBrNFeDANFERave dinamicamente a cada request mas isso gerou um grande overhead e o tempo de resposta de cada requisição ficou meio alto pois tive que enfileirar via CriticalSection para evitar reentrância na unit ACBrNFeDANFERave. 4) Por fim adotei uma solução híbrida, deixei o componente TACBrNFeDANFERave estático por um número fixo de requisições (adotei 100) e quando este valor fosse atingido, o programa destroía e recriava o componente. O fato é que mesmo assim o programa continua a falhar com o tempo devolvendo o o conteúdo do PDF de uma consulta anterior mesmo sendo passado o XML novo com outro IDNFE. Pergunta, alguém passou por um problema parecido e saberia dar uma dica para solução do problema. Antecipo agradecimentos, Dailton Menezes