Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 19 total
Thread 8708s, Memory tables, and CLIENT SERVER
Thu, Sep 7 2006 5:01 PMPermanent Link

Jerry Blumenthal
I am trying to get rid of 8708 problems.  And also, I think that what I
am doing will ease the way to a C/S application eventually.

1. In the OnCreate of my database form, I create memory tables for all
of my major tables.

2. When I want to enter a new record or edit an old one, I call an entry
dialog whose data aware components connect to the memory table.  In the
dialog's OnShow, I put the memory table into Insert or Edit mode, and I
populate the memory table's single record with the appropriate values.

3. When I'm done, I copy the values from the entry dialog into the
actual table and save the record.

This has eliminated 8708's on my largest tables; it seems to be working
really well.  So what I am asking now is whether this method is going to
produce any problems I dont know about, down the line, if I go C/S.

Jerry
D4, dbIsam 2.12
D6, dbIsam 3.4
Thu, Sep 7 2006 10:32 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Jerry,

<< This has eliminated 8708's on my largest tables; it seems to be working
really well.  So what I am asking now is whether this method is going to
produce any problems I dont know about, down the line, if I go C/S. >>

No, it will work exactly the same, although you may want to make sure that
you create the in-memory table using a local session and not the remote
session.  Otherwise, the in-memory table will get stored in the database
server's memory instead of in local workstation memory.

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, Sep 8 2006 2:34 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Tim / Jerry


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

Its possible to get an 8708 on a table with a single user (only with multiple TDBISAMTables pointing to it though I think), and wouldn't updating the real table also possibly cause an 8708 - there's no difference between typing the data in and doing it programmatically is there?

With a large table wouldn't loading it into memory, especially remote -> local slow the startup down to much?

Finally, with multiple users, how do you keep the memory tables and the real table in sync?

Roy Lambert
Fri, Sep 8 2006 7:28 AMPermanent Link

Jerry Blumenthal
Roy Lambert wrote:
> Tim / Jerry
>
>
> I can't see how this will eliminate 8708's.
>
> Its possible to get an 8708 on a table with a single user (only with multiple TDBISAMTables pointing to it though I think), and wouldn't updating the real table also possibly cause an 8708 - there's no difference between typing the data in and doing it programmatically is there?
>
> With a large table wouldn't loading it into memory, especially remote -> local slow the startup down to much?
>
> Finally, with multiple users, how do you keep the memory tables and the real table in sync?
>
> Roy Lambert
>

Roy-
If I am editing a record, I get the record, put the data into a local
memory table on the workstation, make any user changes over the next few
minutes or hours, and then
1. Findkey again
2. table.edit
3. stuff all the data
4. table.post

All four steps are done very quickly because all of the user input has
already been done.  If there is a reason why it should not eliminate
8708s, ok, but the actual fact is that it has.

Jerry
Fri, Sep 8 2006 7:30 AMPermanent Link

Jerry Blumenthal
Tim Young [Elevate Software] wrote:
> Jerry,
>
> << This has eliminated 8708's on my largest tables; it seems to be working
> really well.  So what I am asking now is whether this method is going to
> produce any problems I dont know about, down the line, if I go C/S. >>
>
> No, it will work exactly the same, although you may want to make sure that
> you create the in-memory table using a local session and not the remote
> session.  Otherwise, the in-memory table will get stored in the database
> server's memory instead of in local workstation memory.
>

Tim-

Please clarify for me what I have to do to ensure that I am creating the
table using a local session.

JErry
Fri, Sep 8 2006 8:44 AMPermanent Link

Roy Lambert

NLH Associates

Team Elevate Team Elevate

Jerry


Ah. From my reading I thought you were going to transfer everything (the whole table) across at start up but now I'm guessing just a record as needed in which case I withdraw the time based objections (I think).

8708 is defined in the manual as "Record has been changed or deleted by another user, session, or table cursor in the table '<TableName>'"

I don't see how what you're doing gets round that but I'm sure Tim can tell us Smiley

You still need to think through the synchronisation issues especially for the hours part of "make any user changes over the next few
minutes or hours" or are these single user systems?

Finally forget creating the memory table during form create - use SQL SELECT * INTO "Memory\tablename" or whatever it is for the antiquated versions of DBISAM you use Smiley


Roy Lambert
Fri, Sep 8 2006 9:33 AMPermanent Link

"Robert"
You are masking the problem, sort of disconnecting your check engine light.
You are still potentially overlaying changes made by another user. It is
just that since you have this intermediate table, you don't see the problem.

1) User A loads record A containing value "AAA" into his temp table
2) User B then changes record A from "AAA" to "BBB", and posts
3) User A changes his copy of A from  "AAA" to "XXX" and posts the temp
table. So far, so good
4) User A then edits the disk table (now containing "BBB"), changes it to
"XXX", an posts. Since DBISAM does not detect a difference between the
record as read and the record before post, everything seems normal.

But you have lost the changes made by user B.

IMO, you have gone to a lot of trouble to make your system not multi-user.
You have a briefcase model (or whatever it is called nowadays), with all the
synchronization problems that entails.

I think you are trying to reinvent the wheel in an area that has been
analyzed to death already. You really have two options:

1. Pessimistic locking: if one user is editing the record, nobody else can
get in.
2. Optimistic locking. If, when you are ready to post, DBISAM tells you the
record has been changed by another user, take some action.

The 8708 is not an "error" that needs to be avoided at all costs, like a
disk IO error or a memory error. It is simply a notification that the record
has changed between the time you edited it, and the time you are ready to
post. What you do with that info is up to you. If you simply ignore the
error and post, you will be doing basically what you are doing now with the
memory table, and with a lot less work.

Robert

"Jerry Blumenthal" <jerry@blumenthalsoftware.com> wrote in message
news:1D569B77-1199-4BAE-84AC-95ADF853B5E1@news.elevatesoft.com...
> Roy Lambert wrote:
>> Tim / Jerry
>>
>>
>> I can't see how this will eliminate 8708's.
>>
>> Its possible to get an 8708 on a table with a single user (only with
>> multiple TDBISAMTables pointing to it though I think), and wouldn't
>> updating the real table also possibly cause an 8708 - there's no
>> difference between typing the data in and doing it programmatically is
>> there?
>>
>> With a large table wouldn't loading it into memory, especially remote ->
>> local slow the startup down to much?
>>
>> Finally, with multiple users, how do you keep the memory tables and the
>> real table in sync?
>>
>> Roy Lambert
>>
>
> Roy-
> If I am editing a record, I get the record, put the data into a local
> memory table on the workstation, make any user changes over the next few
> minutes or hours, and then
> 1. Findkey again
> 2. table.edit
> 3. stuff all the data
> 4. table.post
>
> All four steps are done very quickly because all of the user input has
> already been done.  If there is a reason why it should not eliminate
> 8708s, ok, but the actual fact is that it has.
>
> Jerry

Fri, Sep 8 2006 10:57 AMPermanent Link

"Jose Eduardo Helminsky"
Robert

I completely agree with you.

Eduardo

Fri, Sep 8 2006 2:46 PMPermanent Link

Jerry Blumenthal
Robert wrote:
> You are masking the problem, sort of disconnecting your check engine light.
> You are still potentially overlaying changes made by another user. It is
> just that since you have this intermediate table, you don't see the problem.
>
> 1) User A loads record A containing value "AAA" into his temp table
> 2) User B then changes record A from "AAA" to "BBB", and posts
> 3) User A changes his copy of A from  "AAA" to "XXX" and posts the temp
> table. So far, so good
> 4) User A then edits the disk table (now containing "BBB"), changes it to
> "XXX", an posts. Since DBISAM does not detect a difference between the
> record as read and the record before post, everything seems normal.
>
> But you have lost the changes made by user B.
>
> IMO, you have gone to a lot of trouble to make your system not multi-user.
> You have a briefcase model (or whatever it is called nowadays), with all the
> synchronization problems that entails.
>
> I think you are trying to reinvent the wheel in an area that has been
> analyzed to death already. You really have two options:
>
> 1. Pessimistic locking: if one user is editing the record, nobody else can
> get in.
> 2. Optimistic locking. If, when you are ready to post, DBISAM tells you the
> record has been changed by another user, take some action.
>
> The 8708 is not an "error" that needs to be avoided at all costs, like a
> disk IO error or a memory error. It is simply a notification that the record
> has changed between the time you edited it, and the time you are ready to
> post. What you do with that info is up to you. If you simply ignore the
> error and post, you will be doing basically what you are doing now with the
> memory table, and with a lot less work.
>
> Robert
>

I wish you hadnt said that, Robert.

I'll start looking at those two locking options......

Jerry





Fri, Sep 8 2006 3:30 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

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.

--
Tim Young
Elevate Software
www.elevatesoft.com

Page 1 of 2Next Page »
Jump to Page:  1 2
Image