Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB Enhancement Requests and Suggestions » View Thread |
Messages 1 to 10 of 18 total |
suggestions : HA , Single - File Database , Sequences Support |
Tue, Nov 5 2013 9:52 AM | Permanent Link |
ae1080 | 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 |
Tue, Nov 5 2013 2:59 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Sun, Jan 11 2015 3:41 AM | Permanent Link |
ae1080 | Any updates, dates? |
Sun, Jan 18 2015 8:36 PM | Permanent Link |
Peter Evans | 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 |
Mon, Jan 19 2015 6:39 AM | Permanent Link |
Matthew Jones | 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 |
Mon, Jan 19 2015 7:45 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Mon, Jan 19 2015 5:57 PM | Permanent Link |
Barry | 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 |
Tue, Jan 20 2015 5:43 AM | Permanent Link |
Peter Evans | 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 |
Tue, Jan 20 2015 5:49 AM | Permanent Link |
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 |
Tue, Jan 20 2015 5:59 AM | Permanent Link |
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 |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Sunday, May 5, 2024 at 07:30 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |