I need a new database to replace an old DBase style table system.
For most work, I'd go with ElevateDB, and may do with this, but it has
to be able to pick up the table files from one computer and (with an
existing system) transport them to a load of others for use. Key is
that it needs to be able to replace them while running. Plus, it has to
be accessible from C and C++ (Visual Studio), Delphi, and C# (.Net).

I'm thinking that ElevateDB is sort of too grown up for this use, but
would be interested in any thoughts otherwise.

--

Matthew Jones

Matthew Jones wrote:

>  Key is
> that it needs to be able to replace them while running.

I recall a discussion on the backup system - can it work on a live
system without much affect? What about restoring? Can I import/replace
the data while other applications are talking to the database via file
or server service?

--

Matthew Jones

Matthew

>I need a new database to replace an old DBase style table system.
>For most work, I'd go with ElevateDB, and may do with this, but it has
>to be able to pick up the table files from one computer and (with an
>existing system) transport them to a load of others for use. Key is
>that it needs to be able to replace them while running. Plus, it has to
>be accessible from C and C++ (Visual Studio), Delphi, and C# (.Net).
>
>I'm thinking that ElevateDB is sort of too grown up for this use, but
>would be interested in any thoughts otherwise.

It depends on just what you mean by "replace them while running". If you're thinking of the DBISAM approach where you could just delete at OS level and copy the new files in (at least as long as they wern't open) you MIGHT just get away with it. Way back ElevateDB objected to the point of refusal. If you copy files around now its more relaxed about it.

I haven't tried doing it whilst an application is running and the database is open so that would be an interesting experiment.

Thinking about it, because ElevateDB didn't play nice at the beginning, I went for an export, move, wipe target files and import approach. At that time EMPTY TABLE was also lacking so I closed the table, did an OS delete of the table files, opened the table and imported. So unless you have a major structure change I'll bet you should be good to go.

Roy Lambert

Roy Lambert wrote:

> Matthew
>
> > I need a new database to replace an old DBase style table system.
> > For most work, I'd go with ElevateDB, and may do with this, but it
> > has to be able to pick up the table files from one computer and
> > (with an existing system) transport them to a load of others for
> > use. Key is that it needs to be able to replace them while running.
> > Plus, it has to be accessible from C and C++ (Visual Studio),
> > Delphi, and C# (.Net).
> >
> > I'm thinking that ElevateDB is sort of too grown up for this use,
> > but would be interested in any thoughts otherwise.
>
> It depends on just what you mean by "replace them while running". If
> you're thinking of the DBISAM approach where you could just delete at
> OS level and copy the new files in (at least as long as they wern't
> open) you MIGHT just get away with it. Way back ElevateDB objected to
> the point of refusal. If you copy files around now its more relaxed
> about it.
>
> I haven't tried doing it whilst an application is running and the
> database is open so that would be an interesting experiment.
>
> Thinking about it, because ElevateDB didn't play nice at the
> beginning, I went for an export, move, wipe target files and import
> approach. At that time EMPTY TABLE was also lacking so I closed the
> table, did an OS delete of the table files, opened the table and
> imported. So unless you have a major structure change I'll bet you
> should be good to go.

Thanks. I am doing a lot of pondering, and it might be possible to work
on it with some sort of intermediate service. That could delay any
other queries while it did a switch out or something. I think it might
be viable, but have to do a lot more thinking...

--

Matthew Jones

Matthew


Had you thought of using the publishing mechanism? You could leave the existing transport mechanism in place and just transport the published data.

Roy Lambert

Roy Lambert wrote:

> Had you thought of using the publishing mechanism?

I will look into it. Thanks.

--

Matthew Jones