Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 10 of 19 total |
Dbisam and replication ! |
Mon, Jun 22 2015 1:30 PM | Permanent Link |
kamran | Hello All
------------------------------------------------------------------------------------------------------------------ Ref: Tim's Quote: DBISAM has been in "legacy" mode for some time now. We'll continue to release new updates for new Delphi compilers, and try adding little improvements where they can be added. Internally, we still use DBISAM and now have it replicating data back and forth between here and our Chicago web server. If you're interested in this type of functionality for DBISAM, let me know and I'll consider publishing it as part of the product. It's completely fail-safe, and maintains transaction boundaries while replicating. ----------------------------------------------------------------------------------------------------------------- Now that web builder 2 is out.. Tim might have a bit of time for other stuff.. (dbisam) hopefully. As per Tims request if anyone is interested in seeing replication features in dbisam please VOTE for it / let Tim know on this forum or directly by email .. It would be great to have dbisam working with such power for all the dbisam users everywhere. Regards Kamran |
Mon, Jun 22 2015 1:40 PM | Permanent Link |
Jose Eduardo Helminsky HPro Informatica | My vote for replication in DBISAM and if possible, a little more attention to it.
Like Tim comment I have a lot of applications built with DBISAM and customers does not pay for upgrade and therefore it is very hard to support the changes from DBISAM to ElevateDB. I undestand too that is not easy to maintain both versions but this is my wish. |
Mon, Jun 22 2015 3:27 PM | Permanent Link |
Raul Team Elevate | On 6/22/2015 1:30 PM, kamran wrote:
> As per Tims request if anyone is interested in seeing replication features in dbisam please VOTE > for it / let Tim know on this forum or directly by email .. +1 We did end up implementing our own replication already but would be nice to compare it to a more native solution. Raul |
Wed, Jul 8 2015 11:25 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Kamran,
<< Now that web builder 2 is out.. Tim might have a bit of time for other stuff.. (dbisam) hopefully. >> I'll be releasing the DBISAM replication soon. I'm putting out a new DBISAM 4.41 build 2 today, but the replication will show up in a 4.42 release. I just need to clean up the code and document it all. Tim Young Elevate Software www.elevatesoft.com |
Fri, Jul 10 2015 3:52 AM | Permanent Link |
Adam H. | Hi Tim,
> I'll be releasing the DBISAM replication soon. I'm putting out a new > DBISAM 4.41 build 2 today, but the replication will show up in a 4.42 > release. I just need to clean up the code and document it all. It's very exciting to hear that DBISam is getting some additional functions... Thank you. But forget 4.42.... Make it DBISAM 5! All jokes aside though - could it be worth considering a major version release. There could be some other additional features thrown in that would normally not be available for consideration with minor version updates because of breaking changes. I'm not suggesting trying to re-write EDB in DBISAM, but there may be a few things such as: - Increasing the maximum number of index per tables. - Turning on Large File Support by Default (if there's no reason to not have it on by default anymore)? - Maybe even see if there's a wishlist of changes that others might be interested that is easily achievable? (Could be dangerous . - I don't know how difficult it would be, but maybe even if we had some sort of scripting component to match EDB with memory tables / temporary tables. (The thought of this is that it would take me many months to migrate my larger applications to EDB, and it's not feasible as they're constantly having changes made on a weekly basis and new versions released - so I can't stop development to the apps). But if I could change the SQL to match and work the way EDB would whilst still developing in DBISAM - then I might be able to get my applications to a point where migration to EDB could be done within a shorter period of time making such migrations achievable, and then I could have the advantage of everything else that EDB offers after migrating. Plus it might be an extra bit of cash injection for you. I know, I'm probably dreaming - I do recall someone saying DBISAM 5 will never be, but one can live in hope. (There's still people expecting Half Life 3 to be released <vbg>. Which will be released first?) Cheers Adam |
Fri, Jul 10 2015 2:32 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Adam,
<< All jokes aside though - could it be worth considering a major version release. There could be some other additional features thrown in that would normally not be available for consideration with minor version updates because of breaking changes. >> I think about it a lot, and have definitely considered it. It’s really just the thought of re-writing things that I've already written in EDB that makes me cringe a bit. But, things like Unicode support are definitely something that could be done. << - Increasing the maximum number of index per tables. >> That requires a format change, unfortunately. << - Turning on Large File Support by Default (if there's no reason to not have it on by default anymore)? >> It depends - there may be cases where someone is accessing an older shared 32-bit Linux file system, for example. But, for the most part, yes, it could probably go. << - I don't know how difficult it would be, but maybe even if we had some sort of scripting component to match EDB with memory tables / temporary tables. >> This is where things start going down the rabbit hole and you end up with EDB. Remember, EDB originally started out as DBISAM 5. Thanks, Tim Young Elevate Software www.elevatesoft.com |
Fri, Jul 10 2015 3:25 PM | Permanent Link |
Raul Team Elevate | On 7/10/2015 2:32 PM, Tim Young [Elevate Software] wrote:
> I think about it a lot, and have definitely considered it. It’s really > just the thought of re-writing things that I've already written in EDB > that makes me cringe a bit. But, things like Unicode support are > definitely something that could be done. Would love to get a DBISAM with unicode. Replication and unicode as DBISAM v5 would be so worth the upgrade price for us as we could stay on DBISAM and not go thru the move to EDB. Would be curious to know how many others are in the same boat - what the payout for you might be if we all paid upgrade price tpo make it worthwhile to do. Raul |
Sun, Jul 12 2015 8:07 PM | Permanent Link |
Adam H. | Hi Tim,
> << - Increasing the maximum number of index per tables. >> > > That requires a format change, unfortunately. I know - hence the recommendation to release as v5 instead of a minor change. V5 would allow for some 'breaking changes' that your hands are currently tied with for v4. > << - I don't know how difficult it would be, but maybe even if we had > some sort of scripting component to match EDB with memory tables / > temporary tables. >> > > This is where things start going down the rabbit hole and you end up > with EDB. Remember, EDB originally started out as DBISAM 5. I wasn't thinking of stored procs, triggers, etc. The biggest barrier to me changing my large projects to EDB is that to rewrite the thousands (literally!) of queries (some of them quite involved) from DBISAM to EDB to change over would mean a downtime of development and releases that isn't practical. I don't need the new features of EDB in DBISAM. I just need to make DBISAM's queries the same for the current features that match EDB to allow a migration to occur. So, if it was possible to leave DBISAM's memory features just 'as is' - not implementing any EDB ones, but being able to use SQL to execute that is compatible with EDB - then that would allow me to take a year or so to slowly work through the projects whilst still providing update releases in DBISAM to a point where migrating to EDB would be possible. It's probably more of a dream than anything else, but if you never ask. The other option would be to allow EDB to use DBISAM type queries such as select into memory\mytable, but that question has already being raised and answered previously. With a combination of data replication, UNICODE and increasing the index per table - I think a Version 5 release of DBISAM (so v4 doesn't have any breaking changes) might be warranted that might benefit both you (financially) as well as us - and not actually step on EDB's toes. Cheers Adam. |
Mon, Jul 13 2015 12:32 AM | Permanent Link |
Adam H. | Another thought: You could add to v5 a default for LargeFileSupport to
True. (I know that this would not be a good idea with v4 because of legacy supports, etc - but a major change with file structure change to support indexes could support this too)? |
Mon, Jul 13 2015 3:43 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Adam
>I wasn't thinking of stored procs, triggers, etc. The biggest barrier to >me changing my large projects to EDB is that to rewrite the thousands >(literally!) of queries (some of them quite involved) from DBISAM to EDB >to change over would mean a downtime of development and releases that >isn't practical. Unless I'm totally misunderstanding what you're looking for what you're asking Tim to do here is support DBISAM SQL & ElevateDB SQL simultaneously. I don't know just how many differences there are (Tim probably does) but JOIN vs subselects in things like updates & deletes springs to mind. Roy Lambert ps Tim if you do do this can I have the JOIN stuff bunged into ElevateDB please |
Page 1 of 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Sunday, May 19, 2024 at 08:46 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |