Table Open Confidence Question

[EricN]

I have a question regarding opening a table...

Note : You cannot use the <TBL>.CHANGE_BEGIN() method or <TBL>.ENTER_BEGIN() methods on a table that is already in either Change or Enter mode. To determine the current mode, use the <TBL>.MODE_GET() method.

I understand that if I have the particular table already open somewhere else, I must first properly close it there and then open it to perform my next operation. But where I'm a little fuzzy is if I'm attempting, say a change or enter operation in the "parts table" and Jane Doe wishes to perform a change or enter operation in the "parts table" at the same time, thereby simultaneously opening the same table, is there a conflict?

I don't think there is but would like to hear from gurus. :)

Thanks

[Peter.Greulich]

Re: Table Open Confidence Question

If you're talking about the WAS, the above quote doesn't apply. That is only for desktop methods where a user puts a form or browse into change/enter mode and then at the same time uses a tbl. method in xbasic.

[ColinJD]

Re: Table Open Confidence Question

Peter,
I use change and enter mode routinely with the WAS.
-
For enter I find enter mode holds true with some of the field rules declared, like the Auto incriment feature.
And I can get the newly incrimented field value elsewhere.
-
Change I have always assumed would give some error protection. for multiple users, eg locking records to keep other users at bay.
-
-
Eric,
I believe that tables as such are not where the issues are,
Yes theoretically you should only have one table opened by a user at any particular stage. But multiple users should be able to have the same table open at once. Possibly the table mode method only gives you a result of that particular user, not all users. Thus table mode isn't that relevant.
-
I think the real issue is record locking,
Eg John Doe opens a table and moves his index pointer to his_current_record
Now this record in the table should be locked to stop Jane Doe from editing that particular record., You may however permit Jane Doe to view the record, but this is generally the record before John_Doe started editing it eg going back to the last save.
Thus instead of allowing Jane Doe to view the record, and depending on your requirements you may wish to give her a message, such as "This Record is locked as it is being edited by User_Name (John Doe).
-
In some development areas like user accounts with centralised design record locking conflicts are hardly ever problem, in other areas with centralised design record locking considerations should be a critical aspect of the design.
-
But remember if your code does not force John Doe to close his table after edititing it. Then Jane Doe will have a hard time gaining access,
Also often it seems A5 will not process code well where a table is left open
-
Thus from a WAS perspective I'd open and close tables all in a batch type process. Eg in a Dialog use the Initialise to open a table, then get the records you need then Close the table, after John Doe has finished editing, open the table, update the new info, then close the table, immediately before going onto the next task.
This type of access only takes a millisecond on most servers now, thus conflicts are rare, and when one does occur the second or subsequent users are only delayed a millisecond or two.

[Peter.Greulich]

Re: Table Open Confidence Question

Peter,
I use change and enter mode routinely with the WAS.

Colin,

Never mind. I should look before I leap. Somehow I read that as form level methods as vs. table level methods. Thanks for correcting me.

[EricN]

Re: Table Open Confidence Question

Thanks Colin for the detailed response. For my particular situation, the table may be opened by several users at the same time, but rarely, if ever, would it be the same record at the same time.

I do immediately close the table once the/any process that opens a table is complete...

Examples:
tbl.change_end(.T.)
tbl.close()

tbl.enter_end(.T.)
tbl.close()