Quand vous aurez utilisé Issue Manager un certain temps, peut-être aurez-vous des incidents dans la base de données qui n'auront plus d'intérêt pour votre activité courante, par exemple des incidents clos ou qui concernent des applications non prises en charge. Plus la base de données contient d'incidents, plus l'exécution des actions, par exemple des requêtes, est longue. L'archivage des incidents devrait améliorer les performances. Vous pouvez ensuite exécuter des actions sur un plus petit nombre d'incidents actifs (non archivés).
L'archivage des incidents correspond au déplacement des incidents par Issue Manager de DEFECT et des tables afférentes vers ARCHIVE et les tables afférentes. Toutes les informations concernant les incidents sont conservées. (À titre de comparaison, les incidents actifs restent conservés dans la table DEFECT et les utilisateurs peuvent leur appliquer les actions habituelles.)
Les utilisateurs peuvent afficher les incidents archivés dans la page Détails de l'incident mais ils ne peuvent pas leur appliquer des actions puisque ces incidents sont en lecture seule. Les incidents archivés n'apparaissent pas dans les boîtes de réception des utilisateurs. Toutefois, les utilisateurs peuvent toujours exécuter des requêtes, des rapports et des graphiques sur les incidents archivés. L'archivage cache des incidents présents dans la base de données mais ne les supprime pas.
Pour réduire la taille de votre base de données de production, vous pouvez toutefois créer une nouvelle base de données personnalisée dans laquelle vous importerez uniquement les incidents actifs et les informations afférentes depuis la base de données d'origine.
Si vous archivez un incident qui est affiché à l'écran mais pas en cours de modification, l'utilisateur ne verra pas la modification jusqu'à ce qu'il se déconnecte et se reconnecte, qu'il quitte et redémarre, ou qu'il tente d'appliquer une action à l'incident.