[Feature request] Keep opened query tabs across user sessions until user close it manually

I have suggestion of saving all "Query" tabs text on closing, just like in latest Notepad++ version not saved to file tabs are stored even when user close application and restored when his opens it again. Opened tabs just keep existing through application close/open actions until user manually close specific tab(and choose not save in case text was not saved to file)

See Notepad++ sample in attached file

Yes, that was quite often asked by users.

Probably a folder similar to where snippets are stored is a good place to store tab contents:
C:\ProgramData\HeidiSQL\AutoSave

But we need to give it some more logic:
* Very huge files should not get auto-saved, or? Let's say when you have a 1g file in a tab. It's ok when the user wants to have it once in a tab, but should we let him wait the next time he starts HeidiSQL to load such a long time? Note that not only the hard disk time matters here. In files larger than 100mb or so the syntax highlighter will barf with so much data.
* I guess this should be configurable. So we need a new checkbox "Restore query tab contents on restart" in Tools > Preferences > SQL.
* Probably it's a good idea to leave the decision about file sizes to the user, by adding another preference option "Do not restore tabs with more than XY characters".
* Do we really need a special tab-restore dialog when HeidiSQL had crashed for some reason? I mean such a dialog like in Firefox, which asks *which* tabs shall be restored after it has crashed. In Firefox this is most likely due to broken HTML pages which lead to a crash, so the user is able to deselect it. But in HeidiSQL a crash due to an sql file can only be due to its size - so I'd say we need to think about file size, not a crash recovery feature. Right?
* If we don't need a crash recovery, we can just save tab contents when the user exits HeidiSQL normally. Otherwise we would need some auto-save event from time to time, let's say each 5 minutes (and only if content has been modified).

Yes, agreed probably better would be just give user ability to decide on his own which maximum size should be for opening(creating) files. Probably additionally may be useful to give user ability to set size in megabytes with description near this option how much approximate symbols contain 1 mb. Additional alert near this option that if file size would be set too big(for example 1024 Mb) application may be slow(additionally depends on user's hardware configuration).

To simplify implementation(and skip "heavy" as I think auto save feature) it may worth to handle query tabs saving on application closing or crashing, but just skip loading "bad" file(if it was the reason for program crash) instead of give user ability to choose which files should be loaded.
Additionally may be required notify user if available free space on disk is not enough to save not saved queries(files) and just ask in descending order of unsaved files size whether user would like to save first file(and largest one) in some other place - if yes: save file(keep tab open for future session) if no just remove this tab and check whether left tabs may be saved to disk with repeating of previous steps if not.

with today's prices for external storage, any complicated logic to handle low disk space is really anachronistic. have a single alert that says "disk space not sufficient to save all tabs"; if this is shown, insert a stick or usb disk and store tabs on it, then clean up your main disk.

of course, saving things to the cloud in the first place (gdrive, dropbox, ..) would be cool, too. on windows, e.g. WebDrive or a similar client can be used to do this.

1. I suggesting 1 repeating dialog to save files until disk space would be enough(user could clean up hdd before 2-nd), using this dialog user can save file to whatever place he likes using save file dialog(usb, external storage, ftp folder, dropbox, google drive folder etc.)
2. For me personally any additional features to sync(transfer) files to any cloud storage would be useless because maximum that is used for sql files storage is file version systems that handle versioning by itself.

What about this feature? When it will be implemented?

Feel free to take part in the discussion here. I threw some questions in above. For example about crash recovery.

* Do we really need a special tab-restore dialog when HeidiSQL had crashed for some reason? I mean such a dialog like in Firefox, which asks *which* tabs shall be restored after it has crashed. In Firefox this is most likely due to broken HTML pages which lead to a crash, so the user is able to deselect it. But in HeidiSQL a crash due to an sql file can only be due to its size - so I'd say we need to think about file size, not a crash recovery feature. Right?
Yeah! It's a good idea. But only when crash is connected whith sql-file size.
What concerns this

* Very huge files should not get auto-saved, or? Let's say when you have a 1g file in a tab. It's ok when the user wants to have it once in a tab, but should we let him wait the next time he starts HeidiSQL to load such a long time? Note that not only the hard disk time matters here. In files larger than 100mb or so the syntax highlighter will barf with so much data.

I assume that this is quite fantastic scenario. If we make a research among users how many of them use sql files with 1 Gb size, it will be 0.001%. So you shouldn't pay attention to this.

Probably it's a good idea to leave the decision about file sizes to the user, by adding another preference option "Do not restore tabs with more than XY characters".

Maybe, but it's not critical. Users can feel excellent without this.
Don't complicate the work to yourself. All we need is

a new checkbox "Restore query tab contents on restart" in Tools > Preferences > SQL.

Nothing else.

I just posted a similar request today when @ansgar showed me this already existing thread.

+1 for the feature request. Hoping to see it in Heidi soon.

Im have been using the portable version for some months now on a daily basis, and it seems to sometime crash hard on me. Can't repeat it; It just happens once in a while.
Anyway.
Typically I find myself doing one of two things in HeidiSQL:
1. 5-6 query tabs with small queries (for testing/developing)
2. Importing sql files (1mb to 500mb+). For the bigger files, I always import them directly and not into a tab.

The autosave on interval/crash recovery would really help out on #1 (which covers probably 98% of my own usage), whereas #2 doesn't really matter (as I always have the file locally).
I would suspect that is around the same for the majority of the users...?

And about saving (big) files...
When using the portable version from a cloud drive, it is certainly a turn-off, so yeah, I'd agree to having it configurable. Maybe not down to selecting a path, but on the size of the content.

So, with the crashes and sizes in mind, I'd vouch for an autosave.
Maybe something like this:
- "Autosave query tabs" -> [Y|N]
- "Autosave interval" -> [each XX minute|Only on exit]
- "Max query tab size to save" -> [500 kb]
- "Require confirmation on exit if a query tab exceeds max size" -> [Y|N]

Im leaving out the "Restore query tab contents on restart" on purpose, as it would be implied by enabling autosave. (at least in my head :D)
I know not every thinks like that, so the options may need a few lines of tooltip to explain themselves though.

This would certainly be helpfull feature!

It crashes for me too & quite often. The steps to reproduce are simple, just have a query running in one tab & before it finishes another query in another tab. The application will crash.

littlejohn: Thanks, that's quite helpful.

I was initially thinking about a dialog which only asks at application exit, but with keeping the interval-storage of tabs we would need some settings like you proposed.

Could you please announce the approxomate date of implementation of this feature? How many updates/releases should we wait?

It's ready when it's done. I have no hard timelines for new features.

I just had Heidi crash on me, which it still seems to do at the end of query runs on occasion. I lost 16 tabs with test queries and other details in them. Most of them were not lost detail, just lost organization of the tabs which I knew by number to click between. This kind of event is exactly why, 20+ years ago, auto save was created. I find it difficult to understand why modified tabs are not regularly saved, and tabs are not restored on restart. Sure, large files are a problem, but only if they are modified. Most large files are loaded and left there unmodified. So, don't save them to a "tabs" folder as data, instead note that the tab was loaded with a file from disk. On restart, mark the tab as unloaded, and when the tab is selcted, as the user if they want to load a big file. You can keep some statistics in about average disk I/O performance to decide if it might take a while to load. You can provide a cancel-able dialog (also invented 20 years ago) that the user can click to stop the load (or just let them close the tab).

There are lots of ways to do this, lets start by just saving what files are in which tabs, and then unsaved tabs get saved into a directory, as a unique file name. The mapping of the tab# to that file name, is part of an instance of heidi saved state. I can, on some days, have 4-5 instances of heidi opened because it doesn't allow me to run more than one query at a time, and I may need to kill a long running query, or observe the query's running statistics.

This is a great application which is missing some things that will greatly enhance peoples ability to keep track of the plethora of details which can often be present when you are working on real world problems.

2. Importing sql files (1mb to 500mb+)

Where the hell are you getting such 500Mb sql files? I have no idea)) What do you write to them? One can save 10000 books to 500Mb text file. Having such big SQLs speaks about bad architecture.

I have 500mb SQL files which are database dumps for meta data in cloud applications. I run those directly in all cases. It's important to "ignore" these as "modified" and needing to be saved, again. Tab save should save which files are in which tabs. If a tab has not been saved, a unique file name should be generated and that content should be saved periodically, perhaps, but certainly anytime a query is submitted. I regularly have heidisql crash on completion of a query. It should be easy to implement the save of which tabs have which files loaded. Those details should create "instance" based trees of detail that is saved. Each instance of heidisql should have its tabs saved separately. The user should be prompted to restore a "session" when it has the same host that they are connecting to. A simple, save, skip or discard choice set would be fine.

This seems increasingly important now that Windows 10 will eventually force a restart of your system (if you did the free upgrade) to apply Windows updates, even if you keep trying to defer it. It will not-so-gracefully close your applications, and so any unsaved query tabs in Heidi will be lost.

As someone who relies on this software for daily work, I would love to see this as a feature. I use notepad++ for this all the time, it's easy to just jot stuff down and not worry about it disappearing if my computer decides to update and restart on its own, or blue screens or whatever (which happens often). I've got 10 query tabs right now just with different sql statements where I'm trying to get to the bottom of a data issue and it'd be awesome if I didn't have to worry about them just disappearing.

For me, only small files matter (no more than a few megabytes), any data dumps would already be saved somewhere. It's usually complex queries that I care about saving. I'll often copy the queries into Notepad++ as I work on them just so they won't go anywhere.

Wow, PERFECT TIMING. I just ran a query, switched servers, and ran the same query again, and got an application error, and "continue application" is grayed out. Looks like I'm losing my 10 query tabs! Luckily I now know what my data issue is, but still.

Not trying to rip on Heidi, I <3 this program, and this feature would be great.

I don't think there is an issue request in the bug tracker, is there? If not, could someone write a ticket and explain in short what Heidi should exactly do here?

Oh here it is: https://github.com/HeidiSQL/HeidiSQL/issues/140

I also would like to see this.

I use Heidi for any MySQL queries I do, and this would be a very nice enhancement. I have come to rely on this feature in Notepad ++, and it would be really nice in Heidi