BeDesk-Express

Nous constatons que malheureusement certains utilisateurs font un mauvais usage du système de sauvegarde/restauration.

Un des cas de figure de mauvaise utilisation consiste par exemple à essayer de créer une nouvelle base de données “indépendante” en utilisant le système de sauvegarde/restauration local.

Or, on ne peut pas obtenir une nouvelle base de données “indépendante” avec le système de sauvegarde/restauration.

La signature de la base de données d’origine est conservée à l’identique. De cette manière, quelque soit le poste sur lequel la base de données est restaurée, on peut s’assurer d’utiliser toujours la version la plus récente et comportant l’intégralité des données.

Si on essaye de restaurer une version antérieure de la base de données, celle-ci ne pourra pas être activée et on ne pourra pas ajouter des données à la suite d’une chronologie tronquée ou ramenée à un état antérieur 1).

—

Pour créer une nouvelle base de données indépendante, il faut cliquer sur le bouton “créer une nouvelle base de données” et non sur “sauvegarder” puis “restaurer”. Cette dernière procédure restitue la base de données d’origine et ne crée pas une nouvelle base de données distincte.

—

En outre, lors de la restauration d’un fichier de sauvegarde, le nom de la base de données est également conservé. Si on effectue la sauvegarde de sécurité de la base de données appelée “Tests”, le nom de la base de données est également enregistré dans le fichier de sauvegarde. Ainsi, lorsqu’on restitue ce fichier, quelque soit le nom qu’on lui aurait donné, ce sera toujours la base de données “Tests” qui sera restaurée.

Cela pose donc un autre problème, si l’utilisateur a essayé de créer une nouvelle base de données “indépendante” par sauvegarde/restauration. En effet, si on restaure par erreur une sauvegarde secondaire sur le poste d’origine, il y aura conflit non seulement d’identité mais de nom également.

—

Pour résoudre ces multiples problèmes, il faut modifier l’implémentation de sécurisation des bases de données en s’assurant qu’une identité correspondent bien au nom de la base de données. Les 2 éléments constituant en soit une clé composée.

Tout changement de nom de la base de données devrait donc dès lors altérer l’identité de la base de données. Cela aura notamment pour conséquence une invalidation immédiate de la licence. Mais, dans le même temps, cela interdira :

1. l’utilisation de copies invalides ou conflictuelles d’une base de données originale,
2. et la réutilisation des codes d’activation sur plus d’une seule et unique identité.

Il faut aussi permettre au support technique de créer des nouvelles identités pour éviter la perte des données des utilisateurs qui auraient utiliser le système de sauvegarde/restauration dans l’espoir de créer une nouvelle base de données “indépendante” par inadvertance.

Nous constatons également que quelques utilisateurs ont créés plusieurs comptes à partir desquels ils ont acquis plusieurs licences. Ce n’est pas un problème en soit. Cependant, ils utilisent aussi ces codes émanant de plusieurs comptes distincts pour activer une même base de données.

Parfois même les coordonnées associées à ces comptes distincts ne sont pas les mêmes (changement de statuts).

Le service des licences doit être attentifs à cet aspect et organiser le regroupement des codes d’activation sur un seul et même compte pour une même base de données.