Currently working with an application not written in Delphi, using an XML/XLS single file database architecture.  It's not good and has had corruption issues.

I'm working on redeveloping a replacement for the application and of course EDB is my favorite DB.

While I know there's plans for a single file "SQLite" style EDB in the future, it's not there yet.

My needs are:
1. 95% of time, it will be single user on same machine.  So embedded vs C/S wouldn't matter, except when needing multi-user for multi-terminal data entry.
2. The current system is based on a single file for each different event throughout the year,  Each event currently has its own file, which is shared with others for use before, during or after the event and for archival purposes.
3. Internet is not an option as events are usually held outdoors in areas where Internet is spotty via cell.
4. In the very few advanced events, there is multi-terminal with different responsibilities at each terminal. These would be either networked wirelessly or via network cables and a switch.
5. Need to be able to share just a "file" / "backup" for the specific event, without doing full DB backup and restore.

SQLite would work for single file, but it isn't very good with multiple connections to the DB file and of course the datatypes are primitive compared to EDB, not to mention SQL advanced functions.

Suggestions?

Lance

Lance

>1. 95% of time, it will be single user on same machine. So embedded vs C/S wouldn't matter, except when needing multi-user for multi-terminal data entry.
>2. The current system is based on a single file for each different event throughout the year, Each event currently has its own file, which is shared with others for use before, during or after the event and for archival purposes.
>3. Internet is not an option as events are usually held outdoors in areas where Internet is spotty via cell.
>4. In the very few advanced events, there is multi-terminal with different responsibilities at each terminal. These would be either networked wirelessly or via network cables and a switch.
>5. Need to be able to share just a "file" / "backup" for the specific event, without doing full DB backup and restore.

A big requirement is that if you need multi-user at all you need multi-user.

In its current incarnation, and assuming that the configuration/catalog is the same in all instances you should be able to get away with copying the table files in ElevateDB. You could also think about using DBISAM which would definitely work with just copying the table files.

There's also software out there (have a look on Torry - type single file into the search box) that will allow a single file to be treated as an entire file system. I have no idea how well it would work in a multi user environment.

Depending on what information you're handling there's Synopse's Big Table - it uses key/value pairs. I don't think it would be any good for multi user but can't remember - its years ago I looked at it.

Question: what is the problem with doing a full DB backup and restore?

Roy

Roy Lambert wrote:
>>Question: what is the problem with doing a full DB backup and restore?

>>Roy

A regular DB backup and restore would probably be fine.  Just trying to wrap head around how to manage an "Event Open" screen which would list the events to then open.

My guess is when a new event is made, a prompt to ask for the event "file" name is used and then in the catalog, a new DB would be created.  Then in the "Open Event" screen, it would query the catalog and display the list to choose from.

To move an event from one computer to the next, would be as you say, a backup and restore.

On 3/6/2020 2:40 PM, Lance Rasmussen wrote:

> 5. Need to be able to share just a "file" / "backup" for the specific event, without doing full DB backup and restore.
>
> SQLite would work for single file, but it isn't very good with multiple connections to the DB file and of course the datatypes are primitive compared to EDB, not to mention SQL advanced functions.
>
> Suggestions?

Just an idea but assuming it's EDB how many tables do you foresee using ?

EDB has support for keeping config fully in memory (ConfigMemory,
LocalConfigMemory and UseLocalSessionEngineSettings settings).

In theory your app could build the config runtime (database, tables,
users etc) in memory and only things on disk would be actual table files.

Have not used this myself so not sure of limitations but this would
allow you to have "folder with data" for each event (or if you name your
tables uniquely per event then even "all events data in one folder").

There might be complications with table schema if that changes that i'm
not aware of - table files i think do store some some metadata - but
this would remove one part of user managing config.

Raul

Lance


You could do that or you could, as Raul suggests do things in memory. Its easy to provide a list of files (Events) to choose from as long as they have a unique file mask (eg the extension). It looks easier for the users just a bit more difficult for the programmer


Roy Lambert