Change Log
V3.02 25/07/2008
V3.01 29/11/2007
Version 3.0 is a major release with a lot of added functionality in the user interface. Changes include:
- Added tabs for multiple queries open
Warning: using this feature along with "Server cursors"
(i.e using a fetchSize<>0) may create issues as sqlite does not allow updates
when there are pending
open statements. This may create "Deadlocks" and "Locked" errors. To use this feature
safely, either work
in "client" mode, (set fetchSize to 0), which never leaves "open" statement cursors
around, or use a single
query window. In any case, a fetch size <>0 is only needed when you are working
with large result sets
and you want fast response.
- fixed bug with spurious parameters detected in comments
- implemented standard clipboard oeprations in query editor
- Implemented search & replace in query editor , see right-click context menu
- increased length of "recent file list" to 20
- when using the "open database" dialog, any file with extension .db* is
listed under "database files", not just .db3 files.
Remember, you can always associate the program with .anything files,
and it will open them from explorer by double-clicking.
- initial support for int64 datatypes (not uint, unfortunately, delphi does
not support unsigned 64 bit, AFAIK).
this feature needs EXTENSIVE testing, pls help here (DOUG?).
The "standard" way to get the program to recognize an int64 is to create
the column with datatype <int64>. Of course, you can always change the
mapping of sqlite "types" to delphi types via the "format settings" dialog.
since this mapping supports regular expressions, the sky is the limit as to
what you map to what! However, int64's will NOT be supported when no type
info is provided AND you are working in "typed" mode. For typeless mode,
(map all to varchar), there was never an issue with int64.
- added new schema context action : show table info (does a PRAGMA table_info)
- changed storage of options to xml file in APPDATA directory. This means
that previous options will be discarded, and must be entered again.
Sorry for that...
Db-stored options *should* be ok.
to remove db-stored options, drop the table "z_sqliteExplorer_options"
- removed the old style of sql history, which was too limited,
and added a new "snippets" tab in the schema panel. Drag and drop
text from the sql editor to the snippets to create a new snippet.
(use appropriate category node).
Double-click the snippet to paste it to the current cursor position
in the editor. Press DEL to delete a snippet, F2 to rename it.
If a snippet contains the token '@@@', the token will be removed and
the cursor will be placed there. This makes it easy to create 'templates'.
- Snippets added to the "Db" node persist in the database, IF and WHEN
the "format options" is also saved in the database. In other words, they
do not get saved "automatically", you need to press "save ooptions in dB"
(under menu Options) for this to happen.
once this is done ONCE, next time they should get saved automatically.
- nice feature: if a db-specific snippet (stored in the database) is named
"autoexec" (case-sensitive), it will be executed automatically
every time the database is opened. this could be useful for
autoloading extensions, attaching databases, etc etc.
- added Explain Query Plan button.
- added support for Attached Database, and multiple loaded schemas.
table names used from the attached schema should be automatically
formated in 'database'.table syntax.
- option to generate code to re-attach currently attached databases. This can be saved as
a snippet, and can also be set to autoexec.
- New feature for mapping sqlite declared data types to sqlite3Explorer data types.
Normally, the mapping works like this : There is an option in Format Settings that allows you
to define whether you want to disable data typing alltogether,
use my "standard" data types,
(standard in the sense that I consider them standard!), or define your own type mapping.
Type mapping works like this : The declared data type (as in how you declared it when you created
the table) is compared against the list of custom definitions. If a line matches, the column is treated as
being of the respective data type. Otherwise, it defaults to a string, same as when not using data types
at all.
The new feature allows you to compare the type rule to either the declared type, the column name or both.
Since matching can be done via exact match, substring match or regular expression, and rules are evaluated
from top to bottom, with the first matching rule being the one selected, you have a lot of sophisticated (read : dangerous)
ways to create data type maps. This feature was added for folk who already are using declarations of types that are not
consistent with my "standard" ones, and, furthermore, cannot re-define their data.
Elaboration :
Suppose that you have a table that stores date/time values, and you want to be able to view and edit them in Explorer
as dates.
How you do it depends first on how you want to actually store date values. Explorer offers 4 different ways :
a. as strings
b. as Delphi floating point values (My prefered way). Ms Sql also uses this.
c. as Julian Dates (Integer values offset from a base)
d. as Unix epoch dates (integer value offset from a base, different than (c)
Most people use (c) or (d), which means that Explorer will display them as Integer or string values, not good for editing or
viewing. You need to tell Explorer somehow that these values are Dates. You do this by first setting the "date storage" option,
so that the values can be read and writtem correctly, and then by somehow telling Explorer that the particular column is a date.
The easiest and most intuitive way is to use a type declaration. The "standard" default mappins interpet any field with a type string
that contains the word "date" as dates.
If, however, you cannot do this, but you still can use a distinctive type for dates, use your own name, and add it to the custom
mappings of the explorer.
If you cannot do even this, you now have the option to have the mapping engine use the column name as well in order to resolve
the type. In this way, you can apply date/time editing and viewing
to existing data without re-defining the types.
Of course, this is of limited use, as you probably do not want to create a type map that contains all possible column names,
and there could be naming clashes, for example a column named "myDate" is actually a date in one table, and a person's name
in another. You need to be careful with using this kind of mapping, and understand what you are doing!
-
Added support for opening a database by dargging and dropping from the shell.
V2.0 1/12/2005
Version 2.00 is a major release, with a lot of changes and bug fixes. Please
read the full documentation.
Major changes include:
- User-defined data type mapping,see doc.
- Enhancent date/time support, with support for Julian,Unix,Floating and
text formats.
- supports ALTER TABLE ADD COLUMN
- Report engine is now distributed separately. If you use reports,
download the DLL.
- New format for reports, slightly incompatible with the old reports.