2. Progress

Configure tests to allow use of system glib library (glib is required by mdbtools).

Fix copyright, licence and other boring things

Import into KDE CVS

Send Win32 build patch upstream.

Debian packing files

Character sets support

MS Jet4 encodes characters with utf8, so it works out of the box using ICONV library

MS Jet3 encodes characters with ANSI charsets specific to the native operating system's encoding the mdb file has been created on. [1]

Use string2Identifier to import tables with spaces in their name.

(Need to move this into KexiDB from Core first.)

[1] To workaround this problem, MDB Migration driver offers custom option for setting encoding of the database. Then, Import Wizard on importing
gets this option from a user (the default is equal to ANSI code for current "system locale"). This allows to import, e.g. database with ANSI 1250 code page (Central Europe) on a "ANSI 1252" (Wester Europe) system.

3. Creating packages

Much of the work in it's development involved making it build outside the Kexi source tree, including making KexiDB install development files. This should simplify writing other drivers to be developed outside KexiDB, and result in configure tests that can be reused in other projects that need to use KexiDB.

By in-place we mean opening .mdb files without migrating it to other (e.g. more Kexi-compatible) format.

For average Joe user this topic looks quite simple: we're opening .mdb files, doing changes (adding records to existing tables, adding/removing tables, changing schema, designing and executing queries, and so on...). Wait a moment, and take a look at following issues:

Mdbtools provides incomplete write support. Its author already did realy huge reverse-engineering work but, AFAIK, at the time of this writing, adding a new table is at least problematic. For example, people can be fooled on win32 platforms that it's all work well, eg. when recently trying OO.org 2.0beta, but looks like win32's API is used there. Other people reported problems with MS Access files with the same application running on Linux instead of MSWindows.

Reading tables by simple listing rows is only a small part of the task list. To make a full use of database features user needs to be able to perform database SQL queries with joins and row filters (WHERE clauses), no matter if by entering a query statement or by using a GUI tools. Unfourtunately, to be able to do more sophisticated queries than "SELECT * FROM mytable" (which is in fact equal to a simple table opening), we need to add a Query Engine which can perform joins for us transparently, using foreign keys, and also other tasks like: rows filtering, computing expresions and so on. Such engine doesn't exists within MDBtools and it isn't even planned to be developed rapidly in the near future (or can we hope that Sun will sponsor this effort?).

What about reusing such an engine? It's hard or impossible to effectively take SQL engine out of, say, SQLite project and reuse it just by replacing its data storeage layer with .mdb-compatible one. Why? SQLite (and probably most or all engines) are designed and optimized with one particular storage method in mind. Similarity of any such a method to .mdb storage handling seems to be only superficial, e.g. regarding to splitting memory to small pages.

5.2. Detailed Issues Related to mdbtools

Add support for MONEY and DECIMAL values. There is a bug in mdbtools (<0.6) related to handling these data types. DECIMAL value is always fetched as "000000.".

Fields ordering. Sometimes order of the imported fields for the given table is not the same as the one visible in MS Access. This can be related to moving and/or removing columns. To fix on mdbtools level.

5.3. Exporting and Importing design from/to MS Access files

Note: this tool requires running MSA.

There is undocumented feature in MSA allowing to import and export full definition of a single object to a file. Queries, forms, reports, modules, data acces pages and macros can be exported and imported (i.e. all except tables, but tables can be exchanged using msbtools).

The advantage of this method is that we can see the full schema that is probably very similar in terms of layout to what is stored in memory by MSA. Example fragment of a query design listing inserted tables:

Begin InputTables
Name ="Authors"
Name ="Publishers"
Name ="Titles"
End

Note 1: These methods are useful to backup MSA databasese objects. Employed in a loop using VBA can export all the objects in one go (except tables, as already mentioned).

Note 2: Funny, but intellisense "knows" about the signature of the methods while you entering the args. In fact you can use Object browser to find these methods and many other: for example select Application class, press right mouse button and set "Show Hidden Members" option on. You will see grayed names of classes and members. Have fun.

Compound File Binary Format (CFBF) - on-disk storage format of data, opened by MS for use by others and it is now used in a variety of programs; used by MSA and Business Objects.

SNP File Format, based on the Compound File Binary Format (CFBF), used by MSA to store Report Snapshots in a single file which can be viewed and printed by the Microsoft Snapshot Viewer (available as a free download from MS). This allows report output to be exported and viewed on computers which do not have MSA installed.