Combo list locking record

[Phil M]

I have a combo list in which the row source type is an array. There is logic so as to set the ListIndex property to the entry matching the current value in the record detail.

Problem is that when the ListIndex property is updated, a record lock is applied to the record which the combo list pertains to. I verified this by tracing through the code and viewing info displayed with DISPLAY STATUS command immediately before/after the statement.

I have reviewed code in all methods, properties, dataenvironment, etc., and do not find any uses of RLOCK() function for affected record/table. All indexes on table are regular indexes. There is a reference specification with a parent table in the schema details for the database container which table resides.

I don't now if this is cause/contributes to the issue, this is an older app, the original developer binded (aghh) the control source for the combo list directly to a field in the record being locked. (we are unbinding the control sources when feasible as we review the code) Additionally, there is another combo list in a different tab for same data detail stored in a separate table. Thus, use of array for row source so moving record pointer when user modifies one of the selections does not adversely affect the other selection.

Any ideas / suggestions will be appreciated.

Phil

 

[Chris Miller]

I don't know what speaks against binding both the rowsource and controlsource of a combobox.
Locking happens when you

a) RLOCK() / FLOCK()
b) have the workarea in a pessimistic buffering mode (aka locking records as soon as you start modifying them or even locking the whole table depending on the mode
c) when you write automatic locks will be made and also be unlocked once the write operation finished.

You seem to see record locks, so I guess yours is a case of b)



Chriss

 

[TamarGranor]

Why are you unbinding your controls? Binding to fields is one of the powerful things VFP lets you do. Combined with buffering, it makes editing easy.

Tamar

 

[Phil M]

We do unbinding because the original developer used basic functions of VFP. He did not use buffering, transactions, and other techniques for managing creation / updating data in tables as they become available in VFP. Thus, with the binding to tables, anytime a user makes a change to a data value and it is entered incorrectly, the original value is lost.

Phil

 

[Chris Miller]

You have buffering, can verify business rules before doing a tableupdate and nobody aid you must bind to the underlying DBFs, you can also bind to an updatable view or cursoradapter and then the change isnÄt only buffered but no DBF access is not tightly coupled and you have your three tier architecture that can intervene between editing and committing data.

And even when you bind to DBFs, as Tamar said, buffering is keeping changes to go directly to a DBF, you can introduce transactions, even for free tables you have MAKETRANSACTABLE().

Chriss

 

[TamarGranor]

Rather than unbinding everything, wouldn't it be easier to add buffering?

Tamar