Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 24 total
Thread RI
Thu, Feb 1 2007 4:05 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Is there a) an intention to add cascading RI

If Yes is there an intended date for its inclusion

If No forget the question

Roy Lambert

Thu, Feb 1 2007 10:27 AMPermanent Link

Chris Erdal
Roy Lambert <roy.lambert@skynet.co.uk> wrote in news:B5FCE0D8-8FC0-4177-
9705-12FA60AADD4E@news.elevatesoft.com:

> Is there a) an intention to add cascading RI
>

> If No forget the question

Correction:

If No then change to Yes

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 3 + EDB 1.00 build 6)
Thu, Feb 1 2007 3:57 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< Is there a) an intention to add cascading RI >>

There was always an intention of adding it, but the locking architecture
wasn't cooperating.  I'll revisit it again later, but it may have to wait
until a server-only version of EDB is produced with less-restrictive
locking.

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, Feb 2 2007 5:05 AMPermanent Link

Chris Erdal
"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in
news:9FAC5602-BB03-4AF5-8F54-DB5D84C86FED@news.elevatesoft.com:

> Roy,
>
><< Is there a) an intention to add cascading RI >>
>
> There was always an intention of adding it, but the locking
> architecture wasn't cooperating.  I'll revisit it again later, but it
> may have to wait until a server-only version of EDB is produced with
> less-restrictive locking.
>

Roy,

 If you need cascading RI right now you'll find it with Context Database
Designer & Extensions as soon as it's compatible with EDB, at least if
you insert/update/delete via cursors rather than directly with SQL
scripts.

I use it with DBISAM, and after discussing the ins and outs of how it
works...

(see thread in thirdparty starting Aug 15th:
Message-ID: <B831B506-6E10-4000-BB6D-02114341B412@news.elevatesoft.com>
)

.... I find it invaluable.

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 3 + EDB 1.00 build 6)
Fri, Feb 2 2007 6:38 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Chris


First I write software as a hobby and the ROI on Context would be zero.

Secondly its not difficult to build in at the level I need it (it would be easier if Tim had it at the engine level).

Thirdly I might even avoid it if it is built in, I'd need to see. Built in RI makes life easier until things go wrong then the options are nightmare or restore from backup Smiley

Roy Lambert
Fri, Feb 2 2007 10:35 AMPermanent Link

Chris Erdal
Roy Lambert <roy.lambert@skynet.co.uk> wrote in
news:CEC1192C-DC85-49F3-8B3A-2CCF73E4C0BC@news.elevatesoft.com:

> First I write software as a hobby and the ROI on Context would be
> zero.

Fine - very sensible point of view!

> Built in RI makes life easier until things go wrong then the options
> are nightmare or restore from backup Smiley

That's one advantage of client-based rather than server-based RI - the
database knows nothing about it, so you can fix errors by hand with no
server-based RI to interfere.

(Context's RI is all client-based, by the way, just in case anyone else is
lurking)

Of course, the most likely reason for something to go wrong with RI is that
the server didn't notice someone fiddling outside the RI domain, e.g. in a
non-RI-aware client with no server-based RI...
--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 3 + EDB 1.00 build 6)
Fri, Feb 2 2007 2:46 PMPermanent Link

Michael Baytalsky
Hi Chris,

> (Context's RI is all client-based, by the way, just in case anyone else is
> lurking)
Yes, unfortunately that's a bit of a problem. We will support EDB in
extensions, however, we will not provide RI for EDB (at least I didn't
consider this so far), since it's already supported by EDB and there's
no point in duplicating this functionality.

I do hope that Tim will introduce cascade operations into EDB, cause
this seem to be very standard option in every RI implementation. I was
actually under impression that it is supported, so I didn't even try it.
Now, that I realize that it's not supported, we might have to provide
RI, but we'll probably need some customer feedback on that - I would really
prefer not to deal with it, unless absolutely necessary.

Regards,
Michael
Sun, Feb 4 2007 9:18 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim


>There was always an intention of adding it, but the locking architecture
>wasn't cooperating. I'll revisit it again later, but it may have to wait
>until a server-only version of EDB is produced with less-restrictive
>locking.

I know its a bit early to start asking this but when there is a server-only version will there still be a file sharing version?

Roy Lambert
Mon, Feb 5 2007 11:24 AMPermanent Link

Chris Erdal
Michael Baytalsky <mike@contextsoft.com> wrote in
news:D3937ABB-EFCE-4F80-8328-AF057516C09F@news.elevatesoft.com:

> We will support EDB in
> extensions, however, we will not provide RI for EDB (at least I didn't
> consider this so far), since it's already supported by EDB and there's
> no point in duplicating this functionality.

I had hoped you'd have a utility to transfer RI from DBISAM to EDB via
some automatically-generated SQL for EDB, since it's all there in your
designer?

> I do hope that Tim will introduce cascade operations into EDB, cause
> this seem to be very standard option in every RI implementation.

Well, I can only agree there - announcing from early on that EDB would
have RI, but omitting to mention that cascading wouldn't be implemented,
seems a little "léger".

> I was
> actually under impression that it is supported, so I didn't even try
> it.

Well it did seem logical...

> Now, that I realize that it's not supported, we might have to
> provide RI, but we'll probably need some customer feedback on that

perhaps a little customer-pressure on Tim first? After all, he's the one
who got us salivating for RI Wink

<Shout> Nobody else interested? </Shout>

> I would really prefer not to deal with it, unless absolutely necessary.

I feel the same way, and that's why I began using Context Extensions with
DBISAM...

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 3 + EDB 1.00 build 6)
Mon, Feb 5 2007 12:55 PMPermanent Link

Michael Baytalsky
Chris,

> I had hoped you'd have a utility to transfer RI from DBISAM to EDB via
> some automatically-generated SQL for EDB, since it's all there in your
> designer?
That will surely be there! You will need no utility, just change target
database from DBISAM to EDB and it will begin generating SQL for foreign
keys (same true for changes between any two database engines).

However, note, then when migrating to EDB, you will have to start
new schema and start with version 1 (i.e. drop history), cause history
(version update SQLs) will not be converted (makes little sense, imo).

>> Now, that I realize that it's not supported, we might have to
>> provide RI, but we'll probably need some customer feedback on that
> perhaps a little customer-pressure on Tim first? After all, he's the one
> who got us salivating for RI Wink
> <Shout> Nobody else interested? </Shout>
We will probably have to send out invitations for online survey.
Unfortunately, I don't have time to do it right now at all, maybe in a
couple of weeks ;-/. I do hope we find time to release adapter for
EDB before the actual release of EDB final (hopefully less then two
weeks).

>> I would really prefer not to deal with it, unless absolutely necessary.
> I feel the same way, and that's why I began using Context Extensions with
> DBISAM...
I understand. I was just really hoping to leave theses client side RI
features, etc. behind... one day Smile

On the other hand, in EDB you can do it using triggers, probably...
shouldn't be too difficult. There may be problem with circular references
if you have any. Actually, from the users of other database servers,
I've heard that they recommend not to use cascading RI, especially in
case of long cascades or circular references, cause it could really
slow things down significantly and is prone to problems and lockups.
So I can understand Tim's choice - he may see problems which we don't
realize (after all he has to provide a *generic* solution) and it's
better to postpone a feature, then to implement it in a buggy or
unreliable way.


Regards,
Michael
Page 1 of 3Next Page »
Jump to Page:  1 2 3
Image