Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 11 to 19 of 19 total |
8708s, Memory tables, and CLIENT SERVER |
Fri, Sep 8 2006 3:35 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Sep 8 2006 4:23 PM | Permanent 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. Robert |
Fri, Sep 8 2006 4:30 PM | Permanent 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. > 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 PM | Permanent 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. > |
Fri, Sep 8 2006 5:01 PM | Permanent 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 PM | Permanent 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 PM | Permanent 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 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 Page | Page 2 of 2 | |
Jump to Page: 1 2 |
This web page was last updated on Saturday, May 4, 2024 at 12:54 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |