![]() | ![]() Products ![]() ![]() ![]() ![]() |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General Discussion » View Thread |
Messages 1 to 6 of 6 total |
![]() |
Thu, Mar 12 2015 7:15 AM | Permanent Link |
Matthew Jones | I need a new database to replace an old DBase style table system.
For most work, I'd go with ElevateDB, and may do with this, but it has to be able to pick up the table files from one computer and (with an existing system) transport them to a load of others for use. Key is that it needs to be able to replace them while running. Plus, it has to be accessible from C and C++ (Visual Studio), Delphi, and C# (.Net). I'm thinking that ElevateDB is sort of too grown up for this use, but would be interested in any thoughts otherwise. -- Matthew Jones |
Thu, Mar 12 2015 8:24 AM | Permanent Link |
Matthew Jones | Matthew Jones wrote:
> Key is > that it needs to be able to replace them while running. I recall a discussion on the backup system - can it work on a live system without much affect? What about restoring? Can I import/replace the data while other applications are talking to the database via file or server service? -- Matthew Jones |
Thu, Mar 12 2015 8:48 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Matthew
>I need a new database to replace an old DBase style table system. >For most work, I'd go with ElevateDB, and may do with this, but it has >to be able to pick up the table files from one computer and (with an >existing system) transport them to a load of others for use. Key is >that it needs to be able to replace them while running. Plus, it has to >be accessible from C and C++ (Visual Studio), Delphi, and C# (.Net). > >I'm thinking that ElevateDB is sort of too grown up for this use, but >would be interested in any thoughts otherwise. It depends on just what you mean by "replace them while running". If you're thinking of the DBISAM approach where you could just delete at OS level and copy the new files in (at least as long as they wern't open) you MIGHT just get away with it. Way back ElevateDB objected to the point of refusal. If you copy files around now its more relaxed about it. I haven't tried doing it whilst an application is running and the database is open so that would be an interesting experiment. Thinking about it, because ElevateDB didn't play nice at the beginning, I went for an export, move, wipe target files and import approach. At that time EMPTY TABLE was also lacking so I closed the table, did an OS delete of the table files, opened the table and imported. So unless you have a major structure change I'll bet you should be good to go. Roy Lambert |
Thu, Mar 12 2015 8:57 AM | Permanent Link |
Matthew Jones | Roy Lambert wrote:
> Matthew > > > I need a new database to replace an old DBase style table system. > > For most work, I'd go with ElevateDB, and may do with this, but it > > has to be able to pick up the table files from one computer and > > (with an existing system) transport them to a load of others for > > use. Key is that it needs to be able to replace them while running. > > Plus, it has to be accessible from C and C++ (Visual Studio), > > Delphi, and C# (.Net). > > > > I'm thinking that ElevateDB is sort of too grown up for this use, > > but would be interested in any thoughts otherwise. > > It depends on just what you mean by "replace them while running". If > you're thinking of the DBISAM approach where you could just delete at > OS level and copy the new files in (at least as long as they wern't > open) you MIGHT just get away with it. Way back ElevateDB objected to > the point of refusal. If you copy files around now its more relaxed > about it. > > I haven't tried doing it whilst an application is running and the > database is open so that would be an interesting experiment. > > Thinking about it, because ElevateDB didn't play nice at the > beginning, I went for an export, move, wipe target files and import > approach. At that time EMPTY TABLE was also lacking so I closed the > table, did an OS delete of the table files, opened the table and > imported. So unless you have a major structure change I'll bet you > should be good to go. Thanks. I am doing a lot of pondering, and it might be possible to work on it with some sort of intermediate service. That could delay any other queries while it did a switch out or something. I think it might be viable, but have to do a lot more thinking... -- Matthew Jones |
Thu, Mar 12 2015 9:28 AM | Permanent Link |
Roy Lambert NLH Associates ![]() | Matthew
Had you thought of using the publishing mechanism? You could leave the existing transport mechanism in place and just transport the published data. Roy Lambert |
Thu, Mar 12 2015 9:50 AM | Permanent Link |
Matthew Jones | Roy Lambert wrote:
> Had you thought of using the publishing mechanism? I will look into it. Thanks. -- Matthew Jones |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy Policy![]() © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? ![]() |