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

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.

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

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

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

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

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

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.

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)?

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