Just a quick thank you to everyone for another great year.  The ElevateDB
launch went about as well as can be expected for a brand new product, and
many of you purchased the upgrade within the first couple of months, even if
you didn't plan on using the product right away.  We certainly appreciate
this level of support immensely, and it really makes our job here much
easier.

2008 will be our 10th anniversary (in August, to be exact), and we look
forward to a year in which we really move ElevateDB forward as a product.
Here are some things that are on tap for this coming year:

- Multi-platform ODBC driver and development libraries for Linux, Windows
CE, and (hopefully), the Mac.

- Enterprise-level ElevateDB Server with an improved transaction and
concurrency model and support for buffering very large amounts of memory

- Replication and synchronization

- Custom messaging protocol for on-demand messaging to and from client
applications and the ElevateDB Server

Things are progressing well with ElevateDB, and we see it as having a very
long and fruitful existence.

Thanks very much for all of your support, both monetarily and here on the
newsgroups.  We couldn't really do what we do without the customers that we
have, especially when things are late or don't work as expected and we need
a little patience and understanding.

--
Tim and Sam Young
Elevate Software
www.elevatesoft.com

Tim,

Maybe I'm missing or not seeing it myself, but is:
- full RI going to be part of Enterprise EDB?
-Also: is there yet a page where the todo list is (with feature requests
users made etc.)

Keep up the excellent work in 2008!

Regards, Harry

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> schreef in bericht
news:D270C47D-6C94-4A24-A418-FA239437075D@news.elevatesoft.com...
> Just a quick thank you to everyone for another great year.  The ElevateDB
> launch went about as well as can be expected for a brand new product, and
> many of you purchased the upgrade within the first couple of months, even
if
> you didn't plan on using the product right away.  We certainly appreciate
> this level of support immensely, and it really makes our job here much
> easier.
>
> 2008 will be our 10th anniversary (in August, to be exact), and we look
> forward to a year in which we really move ElevateDB forward as a product.
> Here are some things that are on tap for this coming year:
>
> - Multi-platform ODBC driver and development libraries for Linux, Windows
> CE, and (hopefully), the Mac.
>
> - Enterprise-level ElevateDB Server with an improved transaction and
> concurrency model and support for buffering very large amounts of memory
>
> - Replication and synchronization
>
> - Custom messaging protocol for on-demand messaging to and from client
> applications and the ElevateDB Server
>
> Things are progressing well with ElevateDB, and we see it as having a very
> long and fruitful existence.
>
> Thanks very much for all of your support, both monetarily and here on the
> newsgroups.  We couldn't really do what we do without the customers that
we
> have, especially when things are late or don't work as expected and we
need
> a little patience and understanding.
>
> --
> Tim and Sam Young
> Elevate Software
> www.elevatesoft.com
>
>

Harry,

<< Maybe I'm missing or not seeing it myself, but is:
- full RI going to be part of Enterprise EDB? >>

There's full RI in EDB right now, minus cascading updates and deletes.
However, those can be done with a trigger just as easily.

<< -Also: is there yet a page where the todo list is (with feature requests
users made etc.) >>

No, I pulled the old one because it was out-dated and have not replaced it
yet.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:4589FC6B-4115-4371-9ED0-077D35270F33@news.elevatesoft.com:

> There's full RI in EDB right now, minus cascading updates and deletes.

That's quite a minus, IMHO, Tim.

> However, those can be done with a trigger just as easily.

I don't see how writing a trigger for each case is as easy as clicking on
a checkbox - can you explain a little more?

By the way, happy new year to Tim and all the rest of you from the south
of France, where we're expecting our daughter to give us our first grand-
child any day now !

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 4 + EDB 1.04 build 3)

Chris,

<< That's quite a minus, IMHO, Tim. >>

I don't think so.  How many applications are you aware of where the primary
keys of tables change very often ?

<< I don't see how writing a trigger for each case is as easy as clicking on
a checkbox - can you explain a little more? >>

I meant in a relative way.  Granted, it's not as easy as a check-box click,
but it's hardly rocket science to write a trigger to do what you want.
Again, how many tables would you require this type of functionality for ?
It can't be that many.

<< By the way, happy new year to Tim and all the rest of you from the south
of France, where we're expecting our daughter to give us our first grand-
child any day now ! >>

Congratulations !  (in advance   Plus, I'm not sure if I like you
anymore now that I know that you get to spend all of your time in the south
of France.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:B3F5858B-378E-44CF-A62C-AB89B1757441@news.elevatesoft.com:

> Chris,
>
><< That's quite a minus, IMHO, Tim. >>
>
> I don't think so.  How many applications are you aware of where the
> primary keys of tables change very often ?

Ok, I'll give you that, although I had a couple of applications that had
to cope with e.g. JEEP models, versions of models, and optional extras
all suddenly becoming CHRYSLER (and MINI => ROVER, then to BMW, etc),
where it might have been handy.

I have recently been toying with the idea of archiving clients+orders etc
by "negativing" their index number and only working with positive values
for regular stuff, and cascading updates would have made that kind of
thing really easy to implement.

I've now been spoiled by Michael Baytalsky's "Context Database Designer"
and its checkboxes for cascading or throwing an error on deletes/updates
in the Master table of a relationship, which makes things so simple I
don't really want to give it up. He's not going to implement RI for EDB
because it's been announced, and I'm not going to migrate to EDB until I
can see some way to implement what he's given me in DBISAM without too
much trouble (and risk of introducing bugs).

Perhaps cascading deletes (and allowing us to enter an error message per
relationship, which will be popped up if on the contrary master
deletes/updates are not allowed) would be easier for you than cascading
updates? If so, it would a nice first step

<< ...from the south
> of France, where we're expecting our daughter to give us our first
> grand- child any day now ! >>
>
> Congratulations !  (in advance   

Thanks! We're still waiting, but Sophie's been out walking round local
lakes all weekend to encourage the wee one to appear!

Plus, I'm not sure if I like you
> anymore now that I know that you get to spend all of your time in the
> south of France.

Oh well, at least now I know someone liked me for a while...
(only kidding)

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 4 + EDB 1.04 build 3)

Chris,

<< Ok, I'll give you that, although I had a couple of applications that had
to cope with e.g. JEEP models, versions of models, and optional extras all
suddenly becoming CHRYSLER (and MINI => ROVER, then to BMW, etc),
where it might have been handy. >>

Sure, but those types of situations are best left to an admin that can run a
transaction to make such a key change.  Normally you don't want users
changing primary keys willy-nilly.  Another good way to get around such an
issue is to use a non-intuitive primary key with a Name column that contains
the actual name of the entity.  Then, changing the name is as simple as
changing one column.  Of course, that also means a lot more joins with
queries, etc., so the performance may prohibit such a setup.

<< I have recently been toying with the idea of archiving clients+orders etc
by "negativing" their index number and only working with positive values for
regular stuff, and cascading updates would have made that kind of thing
really easy to implement. >>

Unfortunately that kind of archiving really doesn't afford you any of the
normal benefits of archiving, i.e. improving database performance by
off-loading un-used data.

<< I've now been spoiled by Michael Baytalsky's "Context Database Designer"
and its checkboxes for cascading or throwing an error on deletes/updates in
the Master table of a relationship, which makes things so simple I don't
really want to give it up. He's not going to implement RI for EDB because
it's been announced, and I'm not going to migrate to EDB until I can see
some way to implement what he's given me in DBISAM without too much trouble
(and risk of introducing bugs). >>

Just to clarify - EDB does have RI.  It simply doesn't allow for cascading
updates or deletes, which are only one small part of the RI picture.   The
primary importance of RI is to enforce valid relationships between the
primary and foreign keys in tables.  The RI in EDB does not preclude you
from making cascading changes yourself.

<< Perhaps cascading deletes (and allowing us to enter an error message per
relationship, which will be popped up if on the contrary master
deletes/updates are not allowed) would be easier for you than cascading
updates? If so, it would a nice first step >>

I'm not quite sure what you mean by the above.  The main reason that EDB
doesn't have cascading updates/deletes is due to its locking model.  To do
cascading updates and deletes in an efficient manner really requires a
better locking model, preferrably with versioning included.   EDB currently
cannot offer that due to the file-sharing option, but the EDB Enterprise
Server coming out this year will offer a better locking model and cascading
updates/deletes.

<< Thanks! We're still waiting, but Sophie's been out walking round local
lakes all weekend to encourage the wee one to appear! >>

They say that walking helps, so cross your fingers....

<< Oh well, at least now I know someone liked me for a while... (only
kidding) >>

 I'm also amazed when people find me likable.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

>>... but the EDB Enterprise Server coming out this year will offer a better
locking model and cascading updates/deletes

Can the Enterprise EDB server be used with Delphi EDB components, or is it
completely different qua approach?

Regards, Harry



"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> schreef in bericht
news:EBC96FCD-23F2-4BF5-AE62-5D2CE8302D41@news.elevatesoft.com...
> Chris,
>
> << Ok, I'll give you that, although I had a couple of applications that
had
> to cope with e.g. JEEP models, versions of models, and optional extras all
> suddenly becoming CHRYSLER (and MINI => ROVER, then to BMW, etc),
> where it might have been handy. >>
>
> Sure, but those types of situations are best left to an admin that can run
a
> transaction to make such a key change.  Normally you don't want users
> changing primary keys willy-nilly.  Another good way to get around such an
> issue is to use a non-intuitive primary key with a Name column that
contains
> the actual name of the entity.  Then, changing the name is as simple as
> changing one column.  Of course, that also means a lot more joins with
> queries, etc., so the performance may prohibit such a setup.
>
> << I have recently been toying with the idea of archiving clients+orders
etc
> by "negativing" their index number and only working with positive values
for
> regular stuff, and cascading updates would have made that kind of thing
> really easy to implement. >>
>
> Unfortunately that kind of archiving really doesn't afford you any of the
> normal benefits of archiving, i.e. improving database performance by
> off-loading un-used data.
>
> << I've now been spoiled by Michael Baytalsky's "Context Database
Designer"
> and its checkboxes for cascading or throwing an error on deletes/updates
in
> the Master table of a relationship, which makes things so simple I don't
> really want to give it up. He's not going to implement RI for EDB because
> it's been announced, and I'm not going to migrate to EDB until I can see
> some way to implement what he's given me in DBISAM without too much
trouble
> (and risk of introducing bugs). >>
>
> Just to clarify - EDB does have RI.  It simply doesn't allow for cascading
> updates or deletes, which are only one small part of the RI picture.   The
> primary importance of RI is to enforce valid relationships between the
> primary and foreign keys in tables.  The RI in EDB does not preclude you
> from making cascading changes yourself.
>
> << Perhaps cascading deletes (and allowing us to enter an error message
per
> relationship, which will be popped up if on the contrary master
> deletes/updates are not allowed) would be easier for you than cascading
> updates? If so, it would a nice first step >>
>
> I'm not quite sure what you mean by the above.  The main reason that EDB
> doesn't have cascading updates/deletes is due to its locking model.  To do
> cascading updates and deletes in an efficient manner really requires a
> better locking model, preferrably with versioning included.   EDB
currently
> cannot offer that due to the file-sharing option, but the EDB Enterprise
> Server coming out this year will offer a better locking model and
cascading
> updates/deletes.
>
> << Thanks! We're still waiting, but Sophie's been out walking round local
> lakes all weekend to encourage the wee one to appear! >>
>
> They say that walking helps, so cross your fingers....
>
> << Oh well, at least now I know someone liked me for a while... (only
> kidding) >>
>
>  I'm also amazed when people find me likable.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
>

Harry,

<< Can the Enterprise EDB server be used with Delphi EDB components, or is
it completely different qua approach? >>

Well, it can't be used with anything right now (bada-bing ! , but yes,
it will work exactly like EDB does now in terms of the client front-ends and
components.  The differences will be simply a different server .EXE and a
different database format (single-file) that will require a transfer from
the existing format.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
> Harry,
>
> << Can the Enterprise EDB server be used with Delphi EDB components, or is
> it completely different qua approach? >>
>
> Well, it can't be used with anything right now (bada-bing ! , but yes,
> it will work exactly like EDB does now in terms of the client front-ends and
> components.  The differences will be simply a different server .EXE and a
> different database format (single-file) that will require a transfer from
> the existing format.
>
Single file! That outta generate several hundred posts. You might as
well say 'Macs are better than PC's!' or 'Linux is better than Windows!'
or 'The Patriots are already the best football team in history whether
they win the superbowl or not!'.

Haven't you argues against a single file format for years? Just curious.
 Don't care much either way myself

Jim