buffering and locking issues

jmom

In my project my form has a pessimistic row buffering. I did that so when many people are doing data entry at the same time, they do not collide and be on the record at the same time. Before CursorSetProperty("Buffering",2,"alias") when we hit the textbutton "add" it would act like we were on the same record in the table. We wanted to avoid this. I believe this would be the best way to avoid update conflicts. I understand this will cause conflicts with applications try to write to all records in the same table. My question is this: Is it possible to run a query or export information from the pessimistic row buffered table without running into the "Attempting to lock" message

CetinBasoz

It's not the best way to avoid conflicts. I'm even not sure that pessimistic locking has a real world usage anywhere.

You can run a query on a buffered or nonbuffered table using select-sql w/o getting into locking issues.

jmom

The project I am working on was started by someone else. It was set at the form default for buffering and locking. When people were doing data entry at the same time, if they happened to click the add button and save button at the same time, it would combine the two orders (seems to be caused by the update conflict then the TableRevert in the textbuttons parent code). Since I have changed it, we have issues by walking on each other. It appeared when we hit add at the same time we would be on the same record, which is definitely not what we want. I do not wanting anybody changing a record that I am on while I am working on it. I would think that most of everybody else would feel the same. In optimistic buffering, if you would hit the add button and then appends the blank, would you not be on the same record or line in the table

dni

Do you have

SET MULTILOCKS ON

jmom

In the parent code of the textbuttons it sets the multilocks on. I copied the parent code into the updaterows methods of the textbuttons and had to add cursorsetproperty("buffering",5,"alias") right before the getnextMod() and reset it to the original setting just before leaving the method. Also about the project and the form, it was set up where it runs many external prg also. Would it also help to change those prgs int0 some kind of internal form method I am appreciating all this comments I am getting.

dni

If the "prg s" are vfp code you may try to use menu Form>New method to insert them as a form method...

jmom

Yes, they are vfp progams. When I started using VFP, I have never done OOP. All i learned from college and high school was about procedural coding. If I seem outdated or have wierd logic, please bear with me. Anyway, is it possible to have optimistic buffering without stomping all over each other with update conflicts We have several instances of the form that filter out orders not from their own company from the same table. It is very important that company a's orders not mix together with company b's orders on the same record line.

CetinBasoz

Optimistic buffering would work just fine. In buffered mode the record you add is exclusive to you. It's neither seen by someone else on the network nor even by you within the same datasession if you open a second copy of the table.

jmom

Thanks. I got information from a previous post that I had about buffering, if i remember right it was a very helpful article by Andy Kramek. I got the impression if someone was entering info into a table while another was changing info on the same record it caused a update conflict. I am mainly afraid if two or more users hit add and append blank at the same time, they will be on that same line or record in that table. I just thought of something else, does it change this issue if the form is set at the Default DataSession with all free tables.

CetinBasoz

As long as it's buffered, data session is irrelevant. It's next level boundary. You can actually test multiuser scenario on a single machine and on a single VFP session using different datasessions (or with no separate sessions using buffering). The danger is when it's not buffered (append blank doesn't lock the record and 2 different persons might be competing to edit the same record when they think they're attempting to edit theirs).

Your impression is not wrong. If 2 are modifying the same record then it's a conflict. The conflicts' seriousness and solving depend on what type of application it's. It might be as simple as last write wins strategy with no checking on conflicting values or exclusive check, prompt,confirm etc.

In help check for the topic under Multiuser scenarios. There is one nice page I remember that summarizes that conflict and handling step by step.

If you want to lock series of records then it's not the buffering but transactions that you need to check. Buffering and transactions might be together or exclusively. Unfortunately, there are tons of scenarios for each combination so there is no single "best strategy". Even in case of transactions it's recommended you do it in "atomic codes" where locking time of records are kept to a minimum.

I just can't fit "pessimistic" anywhere.

buffering and locking issues

Re: buffering and locking issues

Re: buffering and locking issues

Re: buffering and locking issues

Re: buffering and locking issues

Re: buffering and locking issues

Re: buffering and locking issues

Re: buffering and locking issues

Re: buffering and locking issues

Re: buffering and locking issues