Now i'm working with Trail version, really  i'm impressed with your product, i hope those suggestion come up on your Roadmap
1-  Failover clustering for High Availability.
2- Single - File Database.
3- Sequences Support.
regards,
Ahmed

Ahmed,

<< Now i'm working with Trail version, really  i'm impressed with your
product, i hope those suggestion come up on your Roadmap
1-      Failover clustering for High Availability.
2- Single - File Database.
3- Sequences Support. >>

Thanks.  Sequences aren't asked for very much, but the other two items are,
especially 2).

Tim Young
Elevate Software
www.elevatesoft.com

Any updates, dates?

On 6/11/2013 1:52 AM, ae1080 wrote:
> Now i'm working with Trail version, really  i'm impressed with your product, i hope those suggestion come up on your Roadmap
> 1-  Failover clustering for High Availability.
> 2- Single - File Database.
> 3- Sequences Support.
> regards,
> Ahmed
>

Suggestion 2. Why do you want a Single File Database?

Regards,
  Peter Evans

Peter Evans wrote:

> Suggestion 2. Why do you want a Single File Database?

That's a good question, and though you didn't ask me, I'll give my
answer. One of the products I sell uses a lot of tables, but users need
to share the data, so a single file makes sense. As it happens, I use
DBISAM for the data, so what I do is close all the tables, then zip up
the files into a single file. When the user opens the project, I unzip
it all to a temporary folder, and use it normally. I actually like this
better becuase if the user doesn't want to save changes, then nothing
gets changed. Plus I can store other files in the project without
additional work.

Not ideal for everyone of course, but I suppose it is a solution for
some purposes.

--

Matthew Jones

Peter


I think there are sensible reasons and silly reasons. Some of the latter come from the "one file is easier to manage" mindset. Amongst the sensible reasons is the fact that if its a single file then once Windows has given you a slug of space, or extended the slug its already given you, what you do with it is entirely up to you eg oplocks become a thing of the past. In the case of ElevateDB that means that Tim won't have to work with Windows calls but can implement his own - result, probably, faster operation. It also. potentially, opens up an easier transition to things like Linux since the reliance on Windows calls would be removed.

Roy Lambert

Peter & Roy,

Be careful for what you wish for.

A single file database also has some disadvantages if the database is large.

1) Updating a single row of a single small 5k table causes the incremental backup (Acronis for example) to back up the entire database which could be a hundred gigabytes in size. You could soon run out of backup storage if you are used to using incremental backups.

2) There can be a great deal of internal fragmentation within the single file database. For example. If you create a large table (temporary or not) and then drop it, the single db file will not shrink. In many cases the only way to shrink the database is to unload all of the data into a new copy of the database. This is not a problem for small database because it can be done in a few minutes. But if you have a database that is 300GB, it could take hours to re-build it along with all of the table indexes. This means your single file database is offline for maintenance more often than a multi-file database.

3) There is also garbage cleanup to contend with.

4) If the single file database becomes corrupted, you may be left in the dark as to what tables are affected. Your only alternative may be to restore the previous backup.

I've used a single file database in the past, and it is no panacea.

Barry

On 19/01/2015 10:39 PM, Matthew Jones wrote:
>
>> Suggestion 2. Why do you want a Single File Database?
>
> That's a good question, and though you didn't ask me, I'll give my
> answer. One of the products I sell uses a lot of tables, but users need
> to share the data, so a single file makes sense. As it happens, I use
> DBISAM for the data, so what I do is close all the tables, then zip up
> the files into a single file. When the user opens the project, I unzip
> it all to a temporary folder, and use it normally. I actually like this
> better becuase if the user doesn't want to save changes, then nothing
> gets changed. Plus I can store other files in the project without
> additional work.

Thanks for your prompt reply.
I have switched to ElevateDB but do something similar. 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.

Backup is actually a ZIP of the tables and other stuff that is required.
If a table has been deleted it is not zipped, because it is not there!
The other stuff is subfolders containing other files.

I suppose if the database was in a single file I could still zip up the
other stuff.

However, by having individual tables, I can if investigating a problem,
immediately see the overall situation. This is because tables are only
created when required. If they have table X then they must be using the
new features in the program.

Regards,
  Peter Evans

Roy,
Thank you for your prompt reply.

On 19/01/2015 11:45 PM, Roy Lambert wrote:
>
> I think there are sensible reasons and silly reasons. Some of the latter come from the

"one file is easier to manage" mindset. Amongst the sensible reasons is
the fact that if

its a single file then once Windows has given you a slug of space, or
extended the slug

its already given you, what you do with it is entirely up to you eg
oplocks become a

thing of the past. In the case of ElevateDB that means that Tim won't
have to work with

Windows calls but can implement his own - result, probably, faster
operation. It also.

potentially, opens up an easier transition to things like Linux since
the reliance

on Windows calls would be removed.
>
> Roy Lambert

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 to the transition to Linux - I would have to read more widely on that
topic to have an opinion.

Regards,
  Peter Evans

On 20/01/2015 9:57 AM, Barry wrote:
> Peter & Roy,
>
> Be careful for what you wish for.
>
> A single file database also has some disadvantages if the database is large.
>
> 1) Updating a single row of a single small 5k table causes the incremental backup (Acronis for example) to back up the entire database which could be a hundred gigabytes in size. You could soon run out of backup storage if you are used to using incremental backups.
>
> 2) There can be a great deal of internal fragmentation within the single file database. For example.
If you create a large table (temporary or not) and then drop it, the
single db file will not shrink. In many
cases the only way to shrink the database is to unload all of the data
into a new copy of the database. This
is not a problem for small database because it can be done in a few
minutes. But if you have a database that
is 300GB, it could take hours to re-build it along with all of the table
indexes. This means your single
file database is offline for maintenance more often than a multi-file
database.
>
> 3) There is also garbage cleanup to contend with.
>
> 4) If the single file database becomes corrupted, you may be left in the dark as to what tables are affected. Your only alternative may be to restore the previous backup.
>
> I've used a single file database in the past, and it is no panacea.
>
> Barry

Just as well I do not wish for a single file database...

All your points raise issues that single file database proponents gloss
over.

I do drop tables. I do add tables. (There would need to be a utility
provided so I could see what tables are present in the database.)

I also need to load databases very, very fast. I do this operation fast
by only loading one table initially. I do not load every table.

I also open and close databases, hundreds at a time, and I need to do
this very, very fast.


Regards,
  Peter Evans