Peter Evans wrote:

>  When the user needs to backup their data, what I actually do is
> check whether the database is being used. If it is then the user must
> close it.

FWIW, DBISAM, and therefore I suspect ElevateDB, can do a backup while
the database is live. I have used this to good effect on some data
storage systems - a backup is automatically made every night to a set
location. Obviously you could make the backup, then add that to a zip
with other data.

--

Matthew Jones

I'd certainly hope that a single file facility was an option. Which of
course adds complication and support hassle.

The copying of the database to shrink (optimise) it doesn't have to
take it offline, but it would again add complication. Just as VMWare
can take a snapshot, you'd have a bitmap of the fields that have been
moved to the new copy, so you could read from the old and write to new
while it was migrating, but that would be a devil to debug.

I guess the real solution would be to have all file access go through a
layer that can be a virtual file system or the real one. That after all
is what the OLE files were.

For me, I'd say it shouldn't be a priority over other things.

--

Matthew Jones

Barry


OK just where did you read that I wish for a single file database?

My requirements aren't as extreme as Peter's but I am quite happy with multi file databases. However, I would like to say BRING BACK PICK!


Roy Lambert

Peter

>For me "one file is easier to manage" is not my mindset. (See reply of
>mine to another poster.) Currently I favour the existing multifile approach.

As I said in the last post - bring back PICK. Apart from that I don't care if a database has one file or a couple of hundred. In general terms I either manage files as part of Windows (eg documents) or tables as part of a database application. If I can find where things are and do what I want I'm happy. What I hate is when you can't find the data (Outlook Express anyone) to backup or delete or anything.

>As to the transition to Linux - I would have to read more widely on that
>topic to have an opinion.

Thinking about what I posted I'm not sure I'm right. Unless you have a way to talk directly to the hardware there will still be a need for OS calls so maybe it won't ease the movement.

Roy Lambert

On 1/20/2015 7:02 AM, Matthew Jones wrote:
> FWIW, DBISAM, and therefore I suspect ElevateDB, can do a backup while
> the database is live. I have used this to good effect on some data

Yes but you still incur a DB read lock which can be problematic on very
busy systems.

Raul

Raul wrote:

> Yes but you still incur a DB read lock which can be problematic on
> very busy systems.

I guess that depends on how big your database is, but even with massive
blobs, the backup used to take a second or two. Worth it for the safety
most of the time.

--

Matthew Jones

On 1/18/2015 8:36 PM, Peter Evans wrote:
> Suggestion 2. Why do you want a Single File Database?

I think the real question is not the Single File Database but what
features Tim will implement with it.

Going with single file does allow one to abstract away the OS layer and
start implementing features that would not be as possible with each
table being a separate file.

Locking, proper transaction logs, lock-free backup etc are a lot easier
and also no longer OS dependent so EDB would )more easily) go
cross-platform.

AV issues should go away, one can do more efficient disak space
allocation and possibly implement better EDB data caching.

Barry has a good list of the downsides so i wont cover those but for us
those will be a small price to pay if we get some of the features from
above.

Raul

On 1/20/2015 9:17 AM, Matthew Jones wrote:
> I guess that depends on how big your database is, but even with massive
> blobs, the backup used to take a second or two. Worth it for the safety
> most of the time.

Not large but hundreds of MBs is not uncommon. The problem for us was
that the entire DB was read locked so we ended up customizing the source
and doing table level locks only (for us it was an acceptable compromise)

Raul