* Replace checklist box by a virtual tree with checkboxes
* Make "Maintenance" a single tab on a TPageControl, so there may follow other tools (e.g. issue #529)
* Replace button layout by a combobox
* Add "CHECKSUM" operation and various options
* Add a few notes about where AVs seem to randomly occur when GridPost{Insert,Update,Delete} and EnsureDataLoaded invokes the query logic from outside the main thread.
Fixes issue #659 as far as the grids go, but not for export functions.
- Accounts and existing privileges are presented in a pulldown which makes it as easy to use as a toy
- Adding privileges calls the new SelectDBO dialog which is basically a tree like childwins dbtree
- Updating accounts canonicalizes various odd/legacy mechanisms in the MySQL user system
- Fullfills feature request #1547437 (btw)
- Wants to be tested heavily on different servers
A result of a team work. 1000 thanks to rosenfield for the admin friendly logic implementation, tons of fixes and usability ideas.
TODO: find some sleep command for the batch file, as we sometimes get "access denied" while trying to overwrite the just terminated exe. Seems like taskkill doesn't close all handles itself.
Implements a simple dialog which tells the user if there is some new release or nightly build available. Parses http://www.heidisql.com/updatecheck.php as a .ini file. Download buttons just start the webbrowser currently.
Todo: Automatic invocation of this dialog at regular intervals (for example once a week)
Todo: Automatic download + update + restart
- Change table engine via popupmenu in ListTables
- Edit comment via same popupmenu + an own dialog
Not keeping the same feature in different corners of the application looks more straight forward. Users will have exactly one point where they can modify all table related properties. Should simplify it in the end, although some users will have to get used to it.
1. When user opens a file which is bigger than LOAD_SIZE (currently 5M), ask what to do
2. User can normally open the file, cancel, or use the new mechanism:
3. Load a chunk of LOAD_SIZE of SQL into memory
4. Split chunk with parseSQL into single queries
5. Run queries and go on with 3.
parseSQL is the bottleneck here, very CPU consuming, as it has to take care of different comment-styles and delimiters. So, the above strategy effected a good compromise regarding overall performance on different tests with worst case SQL files:
- "Wide" table exports with many big sized fields => long lines
- "Narrow" table exports with only one mini-sized field, extended INSERTs => short lines
Especially in the latter case it avoids to cause a hellfire of parseSQL-calls
Still seems to have some memory leaks somewhere.
