Hi, Vlad!

> > For those special applications NBACKUP allows to have
> read-only main
> > database file and redirect writes to separate read-write
> storage. :-)
>
> Hmm... you joke, right ? There are many applications like
> catalog of spare parts or libraries or phone book etc which
> distributed on the CD\DVD with big database on it. This
> applications often used embedded engine. Ability to perform
> complex queries with temporary data is very desirable for its
> developers

I am not joking. The operations with read-only databases are limited,
for example constructs which need to create temporary blobs to return
results do not work.
With NBACKUP technology even for embedded engine you can have database
file on read-only media, but redirect changes to the file on hard drive
and work with database in full read/write mode.

> > The benefit of my approach is that it would allow to share 99% of
> > implementation with normal tables motivating us to optimize caching
> > logic, data placement logic and access paths for entire engine, not
> > only for temporary tables.
>
> If you approach allows share 99% of code than mine allows
> 99.5% ;) But i still prefer more complex but more faster page spaces

Ok, ok, Vlad. I'm not saying that your approach is bad.
It may even be somewhat faster than mine from DPM/VIO perspective, but
since temporary data is supposed to be cached there should not be a big
difference in actual IO.

But I still don't understand how you propose to handle indices and
constraints for temporary tables.

> Vlad

Nickolay