Pergunta:
Em geral, há alguma armadilha na atualização de dados de um relatório do SSRS?*
Contexto:
Mais específico, estou falando desse contexto:
- SSRS 2008 (com a opção de atualização, se necessário).
- MSSQL 2008 (com a opção de atualização, se necessário).
- Web.forms ReportViewer 2010 em nosso próprio aplicativo ASP.NET.
Eu só preciso fazer uma pequena atualização do banco de dados. O usuário pode marcar um parâmetro de caixa de seleção " Vou imprimir isso ", que fará uma pequena atualização ou inserção para marcar que o relatório foi executado em um ponto específico no tempo. O relatório mostrará apenas que os itens foram adicionados desde a execução de "impressão" anterior, portanto, filtro minha cláusula WHERE com base nisso, fornecendo ao usuário apenas itens "novos".
A razão pela qual estou preocupado é porque não "parece certo" fazer atualizações de uma ferramenta destinada principalmente à visualização de dados. Por outro lado, com algo tão pequeno quanto o acima, parece a solução mais fácil.
Preocupações específicas:
Aqui estão algumas preocupações específicas que tenho sobre as quais estou buscando informações:
- Segurança : a conexão do relatório precisará ser executada com um usuário com permissão para fazer inserções, onde um padrão mais sensato seria executá-lo para um usuário somente de seleção? Existem ataques conhecidos do tipo sql-injection para SSRS?
- Usabilidade : gostaria de fazer a atualização dependendo se um usuário marca uma caixa de seleção. Não tenho certeza de como isso funcionaria com atualizações e se você pode detectar qual é o formato de renderização ao fazer as consultas (o que me permitiria fazer a caixa de seleção acionar atualizações apenas em - por exemplo - uma exportação de PDF).
- Robustez : declarações de atualização parecem mais propensas a exceções (restrições de violação, etc). Não tenho certeza se existe uma maneira elegante de prevenir, registrar, rastrear e depurar esse tipo de problema.
Honestamente, não faça isso. Sim, é possível fazer isso declarando uma variável global para o seu relatório e, em seguida, passando-a para a instrução que gera o conjunto de resultados para fazer algum processamento antes de retornar os dados, mas é confuso e desaconselhável na melhor das hipóteses. O que quer dizer que no futuro você não vai querer adicionar mais variáveis ao relatório? Neste ponto, torna-se tecnicamente um formulário - que é o que o ASP.NET foi projetado para fazer - não o que o SSRS/ReportViewer foi projetado para fazer.
Você diz que está usando o Report Viewer em um aplicativo da Web ASP.NET - portanto, minha recomendação seria lidar com a lógica de impressão no próprio aplicativo, se puder, e deixar o relatório fazer o que ele faz de melhor. Temos um aplicativo em nossa empresa que produz um relatório de maneira semelhante - e precisávamos rastrear quem estava imprimindo o relatório e quando - fizemos isso desativando a funcionalidade de impressão no relatório e, em seguida, fornecemos a funcionalidade no aplicativo para renderizar o relatório em um PDF e, em seguida, imprimi-lo. Isso nos permitiu ser muito flexíveis no que rastreamos/auditamos e como o relatório foi gerado e onde foi impresso.
Além disso, manter as duas partes da lógica separadas será melhor a longo prazo - por exemplo, se você precisar alterar o relatório, isso pode ser feito externamente ao aplicativo e, em seguida, basta fornecer o arquivo rdl e substituir o antigo. Colocar código no relatório para alterar os dados significa testes extras e confunde os limites das responsabilidades.
Além disso, como você mencionou acima - existe a possibilidade de que os dados possam ser comprometidos de uma forma ou de outra (SQL Injection etc.) O SQL necessário para validar, atualizar e retornar dados tornaria seu relatório mais lento. Isso pode não parecer muito se você tiver apenas alguns usuários, mas se sua base de usuários for grande, pode causar problemas.
Pode parecer a solução mais rápida no momento, mas não é necessariamente a solução certa. Mantenha-o simples e separado e você descobrirá que terá muito menos problemas a longo prazo.
Eu espero que isso ajude.
O que você está descrevendo é mais como um log de impressão onde você insere dados sobre quando e quem solicitou o relatório. Se for assim, é válido. Mas a parte sobre ocultar os dados não está clara em sua descrição. Os dados que você está relatando geralmente não devem ser alterados no banco de dados como parte do processo de relatório. Existem situações em que você deve marcar cada relatório impresso como 'impresso' e, portanto, atualizar seu status, mas pela sua descrição, não consigo ver se esse é o caso.