Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB Enhancement Requests and Suggestions » View Thread |
Messages 11 to 18 of 18 total |
suggestions : HA , Single - File Database , Sequences Support |
Tue, Jan 20 2015 7:02 AM | Permanent Link |
Matthew Jones | Peter Evans wrote:
> 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. FWIW, DBISAM, and therefore I suspect ElevateDB, can do a backup while the database is live. I have used this to good effect on some data storage systems - a backup is automatically made every night to a set location. Obviously you could make the backup, then add that to a zip with other data. -- Matthew Jones |
Tue, Jan 20 2015 7:07 AM | Permanent Link |
Matthew Jones | I'd certainly hope that a single file facility was an option. Which of
course adds complication and support hassle. The copying of the database to shrink (optimise) it doesn't have to take it offline, but it would again add complication. Just as VMWare can take a snapshot, you'd have a bitmap of the fields that have been moved to the new copy, so you could read from the old and write to new while it was migrating, but that would be a devil to debug. I guess the real solution would be to have all file access go through a layer that can be a virtual file system or the real one. That after all is what the OLE files were. For me, I'd say it shouldn't be a priority over other things. -- Matthew Jones |
Tue, Jan 20 2015 8:39 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Barry
OK just where did you read that I wish for a single file database? My requirements aren't as extreme as Peter's but I am quite happy with multi file databases. However, I would like to say BRING BACK PICK! Roy Lambert |
Tue, Jan 20 2015 8:44 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Peter
>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 I said in the last post - bring back PICK. Apart from that I don't care if a database has one file or a couple of hundred. In general terms I either manage files as part of Windows (eg documents) or tables as part of a database application. If I can find where things are and do what I want I'm happy. What I hate is when you can't find the data (Outlook Express anyone) to backup or delete or anything. >As to the transition to Linux - I would have to read more widely on that >topic to have an opinion. Thinking about what I posted I'm not sure I'm right. Unless you have a way to talk directly to the hardware there will still be a need for OS calls so maybe it won't ease the movement. Roy Lambert |
Tue, Jan 20 2015 9:06 AM | Permanent Link |
Raul Team Elevate | On 1/20/2015 7:02 AM, Matthew Jones wrote:
> FWIW, DBISAM, and therefore I suspect ElevateDB, can do a backup while > the database is live. I have used this to good effect on some data Yes but you still incur a DB read lock which can be problematic on very busy systems. Raul |
Tue, Jan 20 2015 9:17 AM | Permanent Link |
Matthew Jones | Raul wrote:
> Yes but you still incur a DB read lock which can be problematic on > very busy systems. I guess that depends on how big your database is, but even with massive blobs, the backup used to take a second or two. Worth it for the safety most of the time. -- Matthew Jones |
Tue, Jan 20 2015 9:18 AM | Permanent Link |
Raul Team Elevate | On 1/18/2015 8:36 PM, Peter Evans wrote:
> Suggestion 2. Why do you want a Single File Database? I think the real question is not the Single File Database but what features Tim will implement with it. Going with single file does allow one to abstract away the OS layer and start implementing features that would not be as possible with each table being a separate file. Locking, proper transaction logs, lock-free backup etc are a lot easier and also no longer OS dependent so EDB would )more easily) go cross-platform. AV issues should go away, one can do more efficient disak space allocation and possibly implement better EDB data caching. Barry has a good list of the downsides so i wont cover those but for us those will be a small price to pay if we get some of the features from above. Raul |
Tue, Jan 20 2015 9:20 AM | Permanent Link |
Raul Team Elevate | On 1/20/2015 9:17 AM, Matthew Jones wrote:
> I guess that depends on how big your database is, but even with massive > blobs, the backup used to take a second or two. Worth it for the safety > most of the time. Not large but hundreds of MBs is not uncommon. The problem for us was that the entire DB was read locked so we ended up customizing the source and doing table level locks only (for us it was an acceptable compromise) Raul |
« Previous Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Saturday, May 4, 2024 at 12:54 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |