Heidisql: amélioration : (ajouter une option) restaurer les requêtes non enregistrées

de plus, il serait bien d'être utile d'appuyer sur F2 sur un onglet de requête pour le renommer en place (sans boîte de dialogue d'enregistrement de fichier) car la requête 1, la requête 2, la requête 3, la requête 4 est difficile à distinguer.

J'ai aussi souvent plusieurs fenêtres ouvertes de HeidiSQL. Dans ce cas, il pourrait vérifier si c'est-à-dire. Query 1.sql existe déjà dans le dossier %appdata% et parcourez le nombre jusqu'à ce qu'il n'y ait plus de collision de fichiers.
Lorsque toutes les fenêtres HeidiSQL sont fermées et qu'une nouvelle instance est démarrée, toutes ces requêtes non enregistrées s'ouvriront à nouveau dans une instance. Cela pourrait devenir désordonné, mais je suppose qu'il n'y a pas moyen de contourner cela. C'est le moment de faire le ménage.

Merci pour le meilleur navigateur SQL sur Windows !

Je pense que le problème avec plusieurs instances pourrait être partiellement résolu si les onglets non enregistrés sont enregistrés dans des sous-dossiers par nom de connexion comme :
%appdata%HeidiSQL\unsaved Queries\[CONNECTION_NAME]\query_*.sql dans mon cas, j'ai l'habitude d'avoir plusieurs instances ouvertes mais connectées à des bases de données différentes.

N'oubliez pas que cette amélioration a été demandée pour la première fois en 2012 :

https://sourceforge.net/p/heidisql/tickets/2991/

Quelques migrations de suivi des problèmes depuis lors...

Merci pour vos efforts, les gars. J'aime beaucoup HeidiSQL, mais j'ai parfois peur de l'utiliser car il ne sauvegarde pas votre travail.

Sincères amitiés

Je vote aussi pour ça. Changement assez simple (en apparence), mais une amélioration majeure de l'expérience utilisateur !

MySql Workbench rouvre même les onglets qui ont été enregistrés mais visibles lorsque le programme est fermé et rouvert, pas seulement les requêtes non enregistrées. Ceci est utile lorsque vous travaillez sur un projet qui nécessite plusieurs requêtes pour être compris, mais qui s'étend sur plusieurs jours en raison d'interruptions de phb :)

J'aimerais aussi voir ça.

J'utilise Heidi pour toutes les requêtes MySQL que je fais, et ce serait une très belle amélioration.

Il s'agit d'une caractéristique essentielle. J'aime Heidi et j'apprécie tous les grands efforts, mais je donnerais la priorité à cela par rapport à d'autres améliorations.

Cette fonctionnalité augmenterait considérablement mon flux de travail, car je n'ai pas le temps d'enregistrer chaque requête - mais je pourrais en avoir besoin plus tard.

Je cherchais cela aussi. Mon collègue m'a dit qu'il aimait Heidi mais c'est une fonctionnalité qui lui manque et qui l'aiderait beaucoup. J'espère qu'il sera bientôt mis en œuvre.

J'attends également cette fonctionnalité avec impatience. Améliorera beaucoup mon expérience.

Cela permettrait également d'économiser ceux qui subissent des plantages fréquents de HeidiSQL et perdent des requêtes volumineuses sur lesquelles ils travaillaient. Souvent, lorsqu'un plantage se produit, une boîte de dialogue d'exception s'affiche et parfois, cliquer sur "continuer" fermera le programme, ou "continuer" ne sera pas disponible. Dans les deux cas, essayer de copier la requête hors de l'onglet avant de fermer la boîte d'exception n'est pas possible et les requêtes non enregistrées sont perdues. Notepad ++ a également cette fonctionnalité et cela m'a sauvé d'innombrables fois.

Salut @ansgarbecker , puisque pas mal de personnes trouveraient cela utile, pouvez-vous nous dire si vous avez déjà travaillé dessus ou quand nous pouvons nous attendre à cela dans une version nocturne ? Bien sûr, vous avez un tas d'autres choses dans votre jalon 10.2. Il ne s'agit pas de précipiter quoi que ce soit, juste de l'information.

C'est l'un des souhaits les plus longs et les plus longs de nombreux utilisateurs, ce sera donc l'une des prochaines fonctionnalités que je vais implémenter.

Fantastique nouvelle, merci @ansgarbecker !

Notepad++ a cette fonctionnalité de restauration, et sa boîte de dialogue de préférences ressemble à ceci :

Alors que HeidiSQL n'a que cette option :

Ainsi, l'approche dans Notepad ++ manque l'option d'ignorer le texte non enregistré dans un onglet sans même l'enregistrer automatiquement.

Afin de ne pas casser cette ancienne fonctionnalité de HeidiSQL, je devrais ajouter un nouvel onglet "Fichiers" à la boîte de dialogue des préférences, contenant cette ancienne case à cocher "_Inviter à enregistrer_". De plus, nous aurons une nouvelle case à cocher comme dans Notepad++, intitulée "_Sauvegarder automatiquement les fichiers non enregistrés_". Cette option s'applique aux onglets _laissés ouverts_ lors de la sortie de HeidiSQL, et non aux onglets _fermés_, contrairement à l'option _Invite_.

Et enfin, je pense qu'il n'est même pas nécessaire de personnaliser l'intervalle d'enregistrement de ces sauvegardes, comme dans Notepad ++. Au lieu de cela, Heidi devrait enregistrer ces fichiers temporaires toutes les 10 secondes, et uniquement si le contenu a été modifié.

Au fait, est-ce une bonne idée d'omettre les fichiers de plus de 10 Mo ? Je suis sûr que ces fichiers plus volumineux sont normalement générés automatiquement. Et cela peut introduire un problème de performances si HeidiSQL, par exemple, doit enregistrer un fichier de 5 Go toutes les 10 secondes.

10 Mo de son beaucoup trop je trouve. Si j'exporte des données au format SQL et que je les colle dans un onglet, je ne veux pas que cela soit enregistré.
10kb ou 100kb seraient déjà de très grosses requêtes.
Qu'en est-il de mettre la taille du fichier comme autre option si vous créez déjà un nouvel onglet de paramètres ? Ma limite serait probablement d'environ 10kb.

Oui, je pense que 10 Mo est énorme pour un fichier. Si vous souhaitez effectuer une personnalisation complète, il peut s'agir d'un champ configurable dans lequel vous définissez la taille maximale en Ko.

Pour s'assurer que cette fonctionnalité est effectuée correctement, il convient de réfléchir à la possibilité de récupérer d'un cache corrompu qui empêche HeidiSQL de se charger correctement, comme une option de ligne de commande pour ignorer le chargement des requêtes enregistrées en arrière-plan, ou au lancement après un crash donner le option pour ignorer le chargement des requêtes enregistrées en arrière-plan qui peuvent l'empêcher de démarrer.

De plus, en ce qui concerne la taille du fichier, je suppose qu'il serait assez simple de compresser les requêtes avant de les enregistrer sur le disque, car le texte SQL est hautement compressible. Les requêtes très volumineuses ont probablement beaucoup de texte répétitif et pourraient être considérablement réduites en taille avec la plupart des algorithmes de compression.

J'aimerais beaucoup cette fonctionnalité. J'aimerais aussi des sushis.

J'apprécierais cette fonctionnalité.

Je pense avoir la plupart des parties de cette nouvelle fonctionnalité prêtes à l'emploi. Certaines chaînes de traduction manquent encore et n'ont probablement pas encore été suffisamment testées. Pour tous ceux qui veulent tester la nouvelle fonctionnalité de restauration automatique :

• mise à jour vers la nouvelle version nocturne
• faites attention aux onglets de requête non enregistrés, soit après le chargement d'un fichier à partir du disque dur, soit sans fichier à l'arrière
• si vous voulez savoir plus exactement ce qui se passe :
  
  
  
  • activez Préférences > Logging > Messages "Debug"
  
  
  • regarder le répertoire créé automatiquement C:\Users\<yourUsername>\AppData\Roaming\HeidiSQL\Backups\
  
  
  • regarder le nouveau fichier d'installation C:\Users\<yourUsername>\AppData\Roaming\HeidiSQL\tabs.ini
  
  

La fonction de restauration automatique est activée par défaut et peut être désactivée dans Préférences > Fichiers > "Rouvrir les fichiers SQL précédemment utilisés..."

Je pense que l'implémentation actuelle n'est pas encore sûre contre l'exécution de plusieurs instances... Veuillez en être conscient si vous utilisez déjà cette fonctionnalité.

rien d'important ne doit rester non enregistré de toute façon. Cela ne peut pas être pire qu'avant la mise en œuvre de la fonctionnalité lorsque toutes les requêtes non enregistrées avaient disparu par défaut.

Pas vraiment. Auparavant, il avertissait des requêtes non enregistrées et ne se fermait pas tant que vous ne les aviez pas enregistrées ou supprimées.
Si atm se ferme sans invite et écrase d'autres requêtes, c'est en effet dangereux. Merci d'avoir signalé @ansgarbecker

• regarder le répertoire créé automatiquement C:\Users\<yourUsername>\AppData\Roaming\HeidiSQL\Backups\
• regarder le nouveau fichier d'installation C:\Users\<yourUsername>\AppData\Roaming\HeidiSQL\tabs.ini

Sera-t-il également implémenté pour la version portable ?

Le portable est le même exécutable que la version normale, il est simplement signalé via le fichier portable.lock. Mais je suppose que votre question était destinée aux répertoires, qui ne sont pas "tout à fait portables". Eh bien, je n'en voyais pas encore la nécessité, mais cela peut avoir du sens. Dans la version portable, le tabs.ini pourrait vivre dans le répertoire avec heidisql.exe, et le répertoire "Backups" pourrait être créé automatiquement en tant que sous-dossier de celui-ci. Cela a-t-il du sens?

Exact, quelque chose comme ça.

Le "tabs.ini" qui se trouvait au même endroit que l'exécutable heidiSql.exe (ainsi que sa configuration), pour toutes les versions, portables et installables.

Le répertoire "sauvegardes" ou que son emplacement pourrait être configuré (soit via l'interface graphique de configuration, soit en éditant le fichier de configuration) ou à défaut, par exemple s'il détecte le fichier "portable.lock" ou 2portable_settings.txt", alors créez les directirios" backups" au même endroit, sinon, dans %appdata%\heidisql (par exemple)

Merci

Fini:
[x] empêche les verrous de fichiers lorsque plusieurs instances accèdent à tabs.ini
[x] stocker les tabs.ini et le dossier de sauvegardes localement en mode portable

Il est toujours possible qu'une instance écrase un fichier de sauvegarde d'une autre instance en cours d'exécution. Alors j'ai pensé que je pouvais ajouter quelque chose comme ceci:

• stocker l'ID de processus actuel dans chaque section de tabs.ini
• lors de la restauration des onglets, vérifiez si l'ID de processus est en cours d'exécution
  
  
  
  • s'il est toujours en cours d'exécution : ne restaurez pas cet onglet
  
  
  • s'il n'est pas en cours d'exécution : remplacez-le par l'ID de processus actuel et l'onglet de restauration
  
  

Lire : la première instance restaure les onglets de la précédente. La deuxième instance et les instances ultérieures ne restaurent pas les onglets, mais peuvent ajouter de nouveaux onglets. De cette façon, aucun contenu d'onglet n'est perdu. Si vous quittez 3 instances avec, disons, 2 onglets, la prochaine instance démarrée devrait restaurer 6 onglets. Ou, si 1 des 3 instances est toujours en cours d'exécution, 4 onglets sont restaurés.

Cela ne semble restaurer que le premier onglet pour moi atm

Edit : il semble que la fonction de restauration des onglets doive être décalée de 1 lors de la restauration ? Je quitte avec 4 onglets de requête ouverts (non enregistrés), puis redémarre HeidiSQL, et je récupère 3 onglets de requête

... puis après avoir réessayé après avoir tapé ceci, il se restaure automatiquement de manière cohérente. Je ne vais pas supprimer ce commentaire moi-même juste au cas où cela nécessiterait d'être examiné

Je viens de tester avec une configuration vierge et la dernière version. Je peux reproduire cela si je ferme très rapidement HeidSQL, avant que le minuteur de 10 secondes pour stocker la configuration de l'onglet n'ait atteint sa première fin. Je pense donc que l'appel de MainForm.StoreTabs lors de la fermeture de HeidiSQL n'est pas déclenché pour une raison quelconque.

=> fixe

La prochaine construction nocturne devrait fonctionner de manière stable avec plusieurs instances HeidiSQL, chacune d'entre elles gérant sa propre configuration d'onglet, écrivant dans le même fichier tabs.ini. Les onglets sont restaurés si aucune autre instance en cours d'exécution ne les utilise.

D'autres problèmes ici ? Merci de signaler si vous en trouvez un.

Quelle formidable amélioration dans mon travail quotidien ! Merci d'avoir pris le temps de mettre cela en place !

Je ferme ce sujet maintenant, car il n'y a pas de plaintes depuis quelques jours, et je ne trouve également rien à changer. Veuillez crier si vous trouvez plus de problèmes.

Je pense que c'était une grande amélioration, mais je pense que la norme avec d'autres applications (par exemple Notepad ++) est que lorsque l'utilisateur ferme manuellement une fenêtre, il lui demande toujours confirmation pour enregistrer ou non le contenu. Ce n'est que lorsque le programme est fermé (par exemple lorsqu'il est mis à niveau vers une nouvelle version) que la sauvegarde automatique s'applique.

Je suis d'accord avec @igitur , c'est un bug lié à ce changement. Les onglets doivent toujours demander si l'utilisateur les ferme dans l'application

Oui, lorsque vous fermez un onglet, il devrait vous le demander. Mais c'est le cas, du moins si vous n'avez pas désactivé cette invite :

N'est-ce pas intuitif en quelque sorte ? Ou peut-être parce que l'utilisateur a tendance à désactiver l'option ?

Ah, alors j'ai mal compris cette question. J'ai supposé que cela signifiait spécifiquement "Continuer à poser cette question" lors de la fermeture des fichiers en bloc (par exemple lors de la fermeture/mise à niveau de l'application).

J'ai coché cette case et mon application ne m'invite pas lorsque je ferme un onglet. J'ai peut-être décoché Keep asking this question dans le passé, mais cela devrait simplement mettre à jour Prompt to save modified files on tab close , oui ?

Edit : Non, vous avez raison, ce sont mes paramètres !

Encore un problème, décrit dans le forum : les fichiers physiquement existants chargés dans un onglet sont restaurés même lorsque l'utilisateur les a fermés lors de la session précédente.

Je viens de corriger cela pour la prochaine version. Les onglets fermés avec des fichiers chargés manuellement ne devraient plus être restaurés lors de la prochaine session.

Peut confirmer le correctif dans la version 10.1.0.5585.

Les paramètres liés doivent-ils également être restaurés ?

Ils ne le sont pas actuellement, mais je suppose qu'ils devraient l'être, n'est-ce pas ? Mais veuillez déposer un autre problème pour résoudre ce problème.