Une recherche sur Google n'a malheureusement rien changé, car la plupart des résultats indiquent la syntaxe à utiliser pour mettre en ligne une base de données après l'utilisation de gfix -shut -force 30 (ou tout autre nombre de secondes) comme gfix -online dbname , et j'ai couru gfix -online dbname avec et sans identifiants de connexion à la base de données en question.
Le message que je reçois est le suivant :
database dbname shutdownCe qui est très bien, sauf que je veux le mettre en ligne maintenant. Il n'est pas question de fermer fbserver.exe (qui tourne sur une machine Windows, c'est Classic Server 2.1.1 mais c'est peut (Super) car nous avons d'autres bases de données qui fonctionnent à partir de cette base et qui ont besoin d'un temps de fonctionnement de presque 24 heures sur 24 et 7 jours sur 7. Le message de l'autre gfix -shut -force ou -attach ou -tran est Target shutdown mode is invalid for database dbname ce qui semble correspondre à la documentation sur ce qui se passe si la base de données est déjà complètement fermée. Les Target shutdown mode invalid Le message apparaît également si j'utilise -online single o -online multi mais pas -online / -online normal .
Les idées et les commentaires sont très appréciés, d'autant plus qu'en ce moment, le temps est un facteur important pour moi. Je vous remercie.
EDIT : La raison pour laquelle j'ai arrêté la base de données est de supprimer les transactions "actives" qui étaient liées à une adresse IP spécifique, et cet ordinateur est mon terminal de développement (en fait une machine virtuelle où je développe des interfaces pour le logiciel de base de données), mais je n'avais pas de processus se connectant à la base de données à ce moment-là. Il me semble qu'il s'agissait de transactions orphelines, et elles n'étaient pas dans les limbes, à ce qu'il paraît. L'exécution d'un balayage manuel ne les a pas effacées, la suppression des lignes de MON$STATEMENTS n'a pas fonctionné, même si Firebird 2.1 est censé permettre d'annuler les requêtes de cette manière. Mon dernier recours a été de "redémarrer" la base de données, d'où le problème ci-dessus.
EDIT 2 : Je viens de le remarquer dans les notes de mise à jour de la version 2.1.3 :
Un problème de régression est apparu lors de l'implémentation des nouveaux modes d'arrêt de gfix lorsque l'arrêt est appelé avec les options -attach ou -tran. Si les connexions sont toujours en vie à l'expiration du délai spécifié, le moteur renvoie un message indiquant que l'arrêt a échoué. Cependant, au lieu de laisser la base de données en ligne, comme il se doit, il la place dans un état "hors ligne" incertain et les connexions ultérieures sont refusées.
J'ai utilisé -shut -force 30 Cela ne devrait donc pas avoir d'incidence. Cependant, après les 30 secondes, l'appel n'est pas revenu correctement, et après avoir attendu environ 3 minutes, j'ai fermé mon tty au serveur (machine virtuelle linux sur le serveur Windows), ce qui a pu ou non interrompre l'opération gfix. Exécution ps ne montre aucun processus gfix. Je me demande si cela n'a pas mis la base de données dans un "état incertain"...
