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


I guess it will be a completely different approach not least because it won't allow file server.

Roy Lambert

Roy

> I guess it will be a completely different approach not least because it
> won't allow file server.

Even if this won´t allow file server I think the main changes will be in the
engine and therefore inside the core of ElevateDB but for this question Tim
is the best person to answer it.

Eduardo

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

Jim,

> 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!'.

Single file formats stink when you need to provide direct multi-user
access (think MDB files). Once you do away with that and insist that ALL
access is via the server process then single file operation is fine
since you just invent your own virtual file system within the container
and use your own locking and caching semantics etc.

There is no contradiction or reversal of position here

Eryk

Cool, I didn't catch that the enterprise edition would be limited to C/S
model. That makes a lot more sense.

Jim
> Jim,
>
>> 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!'.
>
> Single file formats stink when you need to provide direct multi-user
> access (think MDB files). Once you do away with that and insist that ALL
> access is via the server process then single file operation is fine
> since you just invent your own virtual file system within the container
> and use your own locking and caching semantics etc.
>
> There is no contradiction or reversal of position here
>
> Eryk

Jim,

<< Cool, I didn't catch that the enterprise edition would be limited to C/S
model. That makes a lot more sense. >>

Yes, my apologies.  It will be C/S only - no file-sharing.  The existing EDB
products will still have file-sharing access, however, so you basically have
the best of all worlds.

--
Tim Young
Elevate Software
www.elevatesoft.com