Pros:
- ShowDBProperties doesn't reset column layout
- Sort direction is remembered automatically
- Reading columnlist from registry is done once in a TMDIChild, not on each ShowDBProperties
- Hiding/unhiding columns doesn't call ShowDBProperties
- No more hassling with what is called a "default column" or not. popupDBGrid is usable like in Windows Explorer.
- Column layout is stored global, not per session.
Cons:
- Column layout from old settings logic needed to be discarded
Side effect:
- Fixes a potential AV in FormatNumber(str) with empty strings.
- Created an overloaded FormatByteNumber() which can take a string as input
Additionally/Sideeffects:
- Fix vstFreeNode to delete the item from the array, not only free the item itself
- Change/Rename GetSelectedNodesFromVT to GetVTCaptions and give it the ability to return all captions, not only the selected. This function is very useful now and saves writing much redundant code.
A table with 500 columns needed 3 seconds to display in the TSortListView, now that takes less than a half second.
Additionally/Side effects:
- TVTreeData structure moved to helpers.pas to be able to use it in new function GetSelectedNodesFromVT.
- ListTablesEditing dropped. We don't need to disable any shortcut there because there is none set.
- Avoid potential AVs when accessing not created items in TVTreeData.Captions
- Dropping non breaking spaces by adding css attribute border-collapse to table.
- Use the same font and background colors as in the datagrids. Even applies for the colored NULL-fields.
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.
