[AccessD] Next Version of Access 12 Musings on what might happen(RANT)

Hi Erwin

> Well my friends....
> I noticed Ms is using a modified Jet more and more for OS management.

> I'm guessing here but I think to know why MS would stop with Jet.
> Because they are not gooing to put the database in to a filesystem, but
> the filesystem in a database!
> And thats gonna be jet.
> Jet has proven to be so fast and performing, that the only option they
> have to resolve the slowness of NTFS.
> Think about it! Is this not more logical?
> How do you manage a giant list of files in a fast way?

> -Exchange server is proven for years now that Jet can be very fast and
> good.
> -DHCP Server
> -DNS server (not sure)
> -WINS server
> -Briefcase
> All using Jet.


The idea of using a database engine for file storage is not new - it
may even be contradictory as the filesystem itself is a database,
though an extremely basic one where the "engine" is an essential part
of the OS. 

Oracle materialized this idea a couple of years ago; the model is
roughly to cut down the OS (Linux) to handle one set of files - the
database - and add an interface to the engine which mimics a drive.
Nice idea - you may call it a bootable database engine - which gives
you all the power, security, features, and years of experience of a
heavy-duty engine. 

Allow me to quote myself from Oct. 2002:

</quote>

A part of an operating system is at least one file system. But the file
system is nothing more than a specialized database, so storing images
and documents as files just means to store them in another database
system; you can say that an mdb file is a database in a database. When
Drew puts an mdb into a blob field in his Access database, he just goes
one step further.
This is in line with Oracle which ultimately offer their database system
with an extension which allows it to be used as a true file repository
with an interface which simulates a file system. The ring is closed.
However, this Oracle system runs on a rudimentary file system though,
which is optimized for handling the Oracle engine only ...

In fact, storing pictures, documents, etc. - or objects if you like -
outside an mdb only represents two challenges: to keep the pointers to
the file names and these file names in sync, and to handle security.

Meeting the first is not difficult. Adding or updating, say, images is
nothing more than storing the images in a directory and the paths of the
images in the mdb. Deleting an image is done by either removing the file
or deleting the path in the mdb or, preferably, both. Deleting paths to
images creates orphaned files which can be deleted at the same time by
the app or later by a clean-up routine - comparable to compacting the
database file.

Paths can be stored relatively to the mdb file - in the same directory
or one or more subdirectories - or to a preset path which is used as a
prefix; this is useful if you wish to store the files somewhere else
like on another server. The prefix path must, of course, be available
for the user.
Never should you store the absolute path to the files, like "g:\images"
as this may leave the mdb non-portable without a manual update of the
stored paths.

The second challenge, security, is more difficult to handle and will be
specific to the actual environment as the user must have the same rights
to add, update, delete and retrieve files as for the records storing the
paths of those in the Access database. One possible way is to store the
files on the server in a directory with no rights granted for the users
and create groups in Access and for access to the file server directory
with equal rights. Then, when the user opens the app, the group is read
and a mapping of the restricted directory with the actual rights of the
user's group is created by the app.

</quote>

This would also put an end to the discussion of where pictures should
be stored: inside the database or as discrete files.

In this context a cab file is also a small database. As another
example - moving from the cab file to the other extreme - Lotus Notes
invented the idea of storing all documents in a way which is logic and
searchable for the user leaving the physical storage to the engine and
the administrator.

Thus, nothing new here.

/gustav