Icon View Thread

The following is the text of the current message along with any replies.
Messages 11 to 19 of 19 total
Thread 8708s, Memory tables, and CLIENT SERVER
Fri, Sep 8 2006 3:35 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Roy,

<< I can't see how this will eliminate 8708's. >>

It won't completely, but it does mostly by simply bypassing the check that
is done when the record is edited "in-place".  This is possible because the
current record that he is editing is almost always current when edited and
not one that has been sitting idle (and buffered) for some time.

Frankly, I wouldn't recommend bypassing the 8708 exceptions, but enough
people ignore my advice regarding this issue that I'm kind of tired of
objecting at this point. Smiley

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, Sep 8 2006 4:23 PMPermanent Link

"Robert"

"Jerry Blumenthal" <jerry@blumenthalsoftware.com> wrote in message
news:D9F12937-BE6C-4309-B0C3-0D46140C997A@news.elevatesoft.com...
>
> I wish you hadnt said that, Robert.
>

Glad to be of help. Smiley

Robert

Fri, Sep 8 2006 4:30 PMPermanent Link

Jerry Blumenthal
Tim Young [Elevate Software] wrote:
> Roy,
>
> << I can't see how this will eliminate 8708's. >>
>
> It won't completely, but it does mostly by simply bypassing the check that
> is done when the record is edited "in-place".  This is possible because the
> current record that he is editing is almost always current when edited and
> not one that has been sitting idle (and buffered) for some time.
>
> Frankly, I wouldn't recommend bypassing the 8708 exceptions, but enough
> people ignore my advice regarding this issue that I'm kind of tired of
> objecting at this point. Smiley
>


I would never ignore your advice; you and Roy and Robert and others on
this forum have helped me far too many times for me to disregard a
warning from you or them.  I thought I was doing something intelligent
to deal with a problem.  Now, based on Robert's post and your comment
above, I want to rethink this and try to figure out what to do.

I generally enclose all of my multi-table posts within a transaction, so
I suppose I have to start there.  And I also have to figure out how to
deal with an 8708.  I dont really understand why it is that pessimistic
locking does not eliminate the 8708s; after all, if the record is locked
then how can it be changed (etc) by another user's actions on the table?
 If there is an explanation of that somewhere, please point me to it.

But if pessimistic locking is not going to work for me, then I have to
figure out how to deal with optimistic, and how to notify users.  Again,
if there is any kind of nicely detailed discussion someplace, please let
me know.

Jerry Blumenthal
Fri, Sep 8 2006 4:37 PMPermanent Link

Sean McCall
Tim,

How about a method to reset the buffer and handle the 8708 situation
outside of an exception for those who want to (pseudo-code):

TPostSynchKind =
   pskNone,
   pskPriorityTable,
   pskPriorityBuffer);

function TDBISAMTable.PostSynchronize(AKind: TPostSynchKind;
  AForce: Boolean = False): Boolean;
begin
  { I'm sure you wouldn't need a try-except in the engine}
  try
    Post;
    Result := True;
    Exit;
  except
    if not an 8708, raise exception
  end; {try-except}
  Result = False;
  {posting failed due to buffer not matching physical record}
  case AKind of
  pskPriorityTable: begin
     {
     if the primary key was changed, change the buffer to append state.
     if the primary key was not changed,
     refresh the edit buffer from the physical table so it can
     be posted without error
     }
     end;
  pskPriorityBuffer: begin
     {
     if the primary key was changed, change to append state.
     if the primary key was not changed,
     refresh the edit buffer from the physical table
     for all fields but those modified in the buffer.
     }
     end;
  {other options as you see fit}
  else
  end;
  if AForce then begin            
    Post;
  end;
end;

So a developer could make this invisible to the user:

if ATable.PostSynchronize(pkPriorityBuffer) = False then begin
  {validate record again in case changes don't make sense};
  ATable.Post;
end;

or tell the user & let him look again before posting

if ATable.PostSynchronize(pkPriorityBuffer) = False then begin
  {message: Record was changed by another user. Please review'}
  Abort;
end;

or ignore 8708s automatically:

ATable.PostSynchronize(pkPriorityBuffer, True);

or whatever they desire. You could even have a database property
for PostSychronize that will make Post work like a forced PostSychronize
if it is not pksNone & post is called. In otherwords... 8708 errors and
they want a quick fix. MyDatabase.PostSychronize = pskPriorityBuffer and
they will be happy.

Its friday... my mind wanders. Have a nice weekend,

Sean

Tim Young [Elevate Software] wrote:
> Frankly, I wouldn't recommend bypassing the 8708 exceptions, but enough
> people ignore my advice regarding this issue that I'm kind of tired of
> objecting at this point. Smiley
>
Fri, Sep 8 2006 5:01 PMPermanent Link

"Robert"

"Jerry Blumenthal" <jerry@blumenthalsoftware.com> wrote in message
news:A9A2A88D-0585-4027-AE19-D5CC9A8A17C5@news.elevatesoft.com...
>
> But if pessimistic locking is not going to work for me,

It should as far as eliminating this error message, but it creates other
problems, since records can remain locked for long periods. I would suggest
you do the following:

1. Read again the DBISAM documentation on concurrency, etc. which is
excellent. Go to the Elevate site and read the V4 manual, the principles
apply to prior versions.
2. Make a little test program, accessing just one table. One tTable, one
session, one database, one grid, one datasource and one navigator. Should
not take more than a few minutes. Then run two copies, and experiment with
the different options.
3. Once you are happy with the behavior you want, transfer it to your
application.

R

Fri, Sep 8 2006 5:44 PMPermanent Link

Jerry Blumenthal
Robert wrote:
> "Jerry Blumenthal" <jerry@blumenthalsoftware.com> wrote in message
> news:A9A2A88D-0585-4027-AE19-D5CC9A8A17C5@news.elevatesoft.com...
>> But if pessimistic locking is not going to work for me,
>
> It should as far as eliminating this error message, but it creates other
> problems, since records can remain locked for long periods. I would suggest
> you do the following:
>
> 1. Read again the DBISAM documentation on concurrency, etc. which is
> excellent. Go to the Elevate site and read the V4 manual, the principles
> apply to prior versions.
> 2. Make a little test program, accessing just one table. One tTable, one
> session, one database, one grid, one datasource and one navigator. Should
> not take more than a few minutes. Then run two copies, and experiment with
> the different options.
> 3. Once you are happy with the behavior you want, transfer it to your
> application.
>
> R
>
>

That will be my project for the next week.  Thanks.
Jerry
Fri, Sep 8 2006 6:20 PMPermanent Link

Jerry Blumenthal
Tim Young [Elevate Software] wrote:
> Jerry,
>
> << Please clarify for me what I have to do to ensure that I am creating the
> table using a local session. >>
>
> Just make sure that it (the TDBISAMTable component) is hooked up to a local
> session via its SessionName property when you create the table and open it
> up.
>


I dont see in the Locking and Concurrency docs for version 2.12 where it
talks about optimistic vs pessimistic protocols.  And when I try to set
the session component's LockProtocol property, I get an error= there is
no such property.

Does v2 not have a setting for optimistic protocol?

Jerry
Sat, Sep 9 2006 10:42 AMPermanent Link

Jerry Blumenthal
Jerry Blumenthal wrote:
> Robert wrote:
>> "Jerry Blumenthal" <jerry@blumenthalsoftware.com> wrote in message
>> news:A9A2A88D-0585-4027-AE19-D5CC9A8A17C5@news.elevatesoft.com...
>>> But if pessimistic locking is not going to work for me,
>>
>> It should as far as eliminating this error message, but it creates
>> other problems, since records can remain locked for long periods. I
>> would suggest you do the following:
>>
>> 1. Read again the DBISAM documentation on concurrency, etc. which is
>> excellent. Go to the Elevate site and read the V4 manual, the
>> principles apply to prior versions.
>> 2. Make a little test program, accessing just one table. One tTable,
>> one session, one database, one grid, one datasource and one navigator.
>> Should not take more than a few minutes. Then run two copies, and
>> experiment with the different options.
>> 3. Once you are happy with the behavior you want, transfer it to your
>> application.
>>
>> R
>>
>>
>
> That will be my project for the next week.  Thanks.
> Jerry

Unfortunately, my app is still written in D4 and dbisam 2, so the
session doesnt have a LockProtocol property.  I'll experiment with D6
and dbisam3, and then decide what to do.

Jerry
Mon, Sep 11 2006 4:42 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Jerry,

<< I would never ignore your advice; you and Roy and Robert and others on
this forum have helped me far too many times for me to disregard a
warning from you or them. >>

No worries, I was basically kidding around anyways.

<< I thought I was doing something intelligent to deal with a problem.  Now,
based on Robert's post and your comment above, I want to rethink this and
try to figure out what to do. >>

Well, Robert is correct - you are possibly just overwriting changes without
knowing it.  If that's what you want to do, then go for it.  However, if it
isn't what you want, then the best bet would simply be to allow the default
8708 firing to occur and deal with them in an OnEditError and/or OnDelete
error event handler.

<< I generally enclose all of my multi-table posts within a transaction, so
I suppose I have to start there.  And I also have to figure out how to
deal with an 8708.  I dont really understand why it is that pessimistic
locking does not eliminate the 8708s; after all, if the record is locked
then how can it be changed (etc) by another user's actions on the table?  If
there is an explanation of that somewhere, please point me to it. >>

It's not telling you that the record has changed *after* it is locked.  It
is telling you that the record has changed *before* it is locked.  IOW, an
8708 error on an Edit is telling you that what was in the
TDBISAMTable/TDBISAMQuery record buffer that you might have been viewing or
using in a search does not match what is being edited now due to changes by
another user or cursor.  Therefore, you should take appropriate actions to
remedy the situation by refreshing the dataset and continuing or informing
the user.

--
Tim Young
Elevate Software
www.elevatesoft.com

« Previous PagePage 2 of 2
Jump to Page:  1 2
Image