In your blog of 10 Apr 18 "Product Status Updates for April 2018"

>>Going forward with ElevateDB, our main areas of effort will be in finishing the OS ports for Linux, Mac, Android, and iOS, as well as other lesser features like nested transactions and support for AES encryption.

For me I see as valuable "finishing the OS ports for Linux, Mac, Android, and iOS".

>>We are also still working on a single-file format for ElevateDB, and hope to have something available by the start of 2019.

I am not sure what this means. Currently a table has a number of files.
I can see those in a disk drives folder.

Will all those files be hidden within a single file?

>>In addition, the ElevateDB Manager will be getting a facelift to match the UI of the Elevate Web Builder 3 IDE.

I do not know what that UI looks like so can not comment.

Regards,
 Peter Evans

Peter,

<< For me I see as valuable "finishing the OS ports for Linux, Mac, Android, and iOS". >>

Yes, and those are the hardest to complete - the next-gen compilers for Delphi require marshalling and other measures to do things that were previously straight API calls to the OS.

<< Will all those files be hidden within a single file? >>

Yes.

<< I do not know what that UI looks like so can not comment. >>

The Elevate Web Builder 3 image in the blog post shows the UI:

https://www.elevatesoft.com/blog?action=view&id=product_status_april2018

Tim Young
Elevate Software
www.elevatesoft.com

Do you forsee any major performance hits as a single file vs as is?   I really am looking forward to this concept of moving all my flat files in a data file (same file name, different extensions) to be a single file (or appearance as one) and then just simply open the data file and go to it.


Tim Young [Elevate Software] wrote:

<< Will all those files be hidden within a single file? >>

Yes.

Tim Young
Elevate Software
www.elevatesoft.com

Lance Rasmussen wrote:

>>Do you forsee any major performance hits as a single file vs as is?   I really am looking forward to this concept of moving all my flat files in a data file (same file name, different extensions) to be a single file (or appearance as one) and then just simply open the data file and go to it.

I too am interested in the performance of this enhancement.

What reasons lie behind this proposal?

Regards,
 Peter Evans

Peter

>I too am interested in the performance of this enhancement.

I'd say performance depends almost totally on how Tim implements it

He should be able to take out some OS stuff, and also, possibly, move from TDataset where I think there would be a lot of potential for improvement.

>What reasons lie behind this proposal?

1. Its been asked for
2. Performance improvements
3. Easier to develop for multiple platforms
4. Better interaction with applications (click on the database and open it up in EDBManager or your app)
5. Easier for Tim to maintain / enhance

I'm sure there are a lot of others.


Roy

Roy Lambert wrote:

3. Easier to develop for multiple platforms

I do a lot of Android development. I can't see why it would be any easier.

4. Better interaction with applications (click on the database and open it up in EDBManager or your app)

Tim stated, inter alia, that it is only the table files that become one file for that table.
So a database will still consist of files corresponding to one each for each table.

5. Easier for Tim to maintain / enhance

Why?

Regards,
 Peter Evans

Peter


>3. Easier to develop for multiple platforms
>
>I do a lot of Android development. I can't see why it would be any easier.

First let me offer my sympathy but I was referring to Tim not the likes of us.

Currently ElevateDB relies heavily on OS calls. If all it needs to do is open one file then do its own thing then dirty great chunks of code which are now different for each platform will be the same.

>4. Better interaction with applications (click on the database and open it up in EDBManager or your app)
>
>Tim stated, inter alia, that it is only the table files that become one file for that table.
>So a database will still consist of files corresponding to one each for each table.

I don't recall seeing that anywhere. Can you point me at where this is?

>5. Easier for Tim to maintain / enhance
>
>Why?

As above - less variance in the code base, less IFDEFs, simpler compile runs.

Roy

On 5/13/2018 3:08 AM, Roy Lambert wrote:
> 1. Its been asked for
> 2. Performance improvements
> 3. Easier to develop for multiple platforms
> 4. Better interaction with applications (click on the database and open it up in EDBManager or your app)
> 5. Easier for Tim to maintain / enhance
>
> I'm sure there are a lot of others.

Tim will be best to address this but few other items AFAIk that would
benefit from single-file model
- fail-safe storage in the future
- better high-concurrency (transactions)
- caching and storage improvements etc
- backup most likely


Raul

On 5/13/2018 3:26 AM, Peter Evans wrote:
> I do a lot of Android development. I can't see why it would be any easier.

Locking, backup etc. What do you use on Android today? SQLite is also
single file database.

> Tim stated, inter alia, that it is only the table files that become one file for that table.

Where? My interpretation of the hints his dropped is different though of
course since it's not ready we're all just speculating.

> So a database will still consist of files corresponding to one each for each table.

I believe you're just making an assumption here.

Single file database IMHO makes sense when it's true single file - this
would eliminate (most) platform dependencies, solve things like locking,
transactions, backup etc.


> Why?

Platform dependency is one aspect (different OS calls vs capabilities
available and how they work and even something as trivial as file system
differences and limitations). This would allow Tim to actually add new
features faster.

Now i'm making an assumption but goal i think also is to drive the EDB
product itself forward and provide additional capabilities that do not
exist today. Single file database is just part of that - fail safe
storage, better concurrency, better caching, replication and backup are
couple of things i can think when single-file would really help.

Raul

I asked the following :-

I am not sure what this means. Currently a table has a number of files.
I can see those in a disk drives folder.

Will all those files be hidden within a single file?

Tim Young replied "Yes".

So it has not been said that there will be one file for the whole database.

Quite clearly there will still be many files in a database. For file for each table.