Thanks for responding.

>THIS.VALUE = davidtable.workordernumber &&or whatever the field is
>THIS.REFRESH

I'll try this. I have shied away from using the .value property up to this point because the documentation clearly states the it contains the 'type' of the value being displayed. By it's name, I would expect it to contain a value equal to the value displayed and of the same type (even though what is displayed is always a text string). Is this true?

>>(2) I open the table in pessimistic record buffering mode.
>
>Do yourself a favour and use optimistic buffering. This will prevent a user leaving for lunch while editing a record and causing a huge headache for everyone. See John's buffering article (follow the hyperlink) on how to use optimistic buffering.

I understand the user-frienliness of optimistic buffering. But right now I'm looking for something that's programmer friendly. It's simpler to deny write access until a record is released than to address the issues of resolving whose copy gets priority when two or more have changed it. For now, I'd rather keep it simple until actual use proves the pessimistic approach to be too limiting.

>
>>[Invisible TABLEUPDATE problem ...
>
>Put a SET STEP ON on the lostfocus of one of the controls that is causing the behaviour some of your code must be doing this.

I'll try that. I think I can eliminate all of my code except for the refresh that occurs when the value is changed. (Which I've tried once already). But I'll play with the debugger a little more using your suggestion to see if I can catch it. (Does the form refresh default code cause a table update?)

>It must be your code doing this.


>>(3) [Rambling stuff which basically says, I'd like to use the 'Incremental Search' feature with the combobox but it's behavior is not realiable. Entering a value that's in the combobox list does not always cause that value to be selected even if the keys are entered well within the double-click timeout.]

Is the incremental search known to have flakey behavior? Do people avoid it or program their own equivalent by hand?

>You lost me on this one.

I hope my restatement is clearer. Please try again if yes.

>Don't put the controlsource of the combo to the field if you don't want the combo to change the value.

Check.

>Also you might want to choose a different way of navigating to a new record since you may go beyond the capibility of the combo if you have too many records.

You lost me here. It's true that the table is not very long now (about 200 records) but this could change. Not sure what you mean by 'beyond the capability of the combo'. I actually started out using a one-column grid (per a suggestion from Jim Booth), but the combo or list seemed like a simpler mechanism for what I wanted to do. Also, I thought it might have been the grid that was causing my row buffering setting to be ignored. (item 4 below)

>
>>(4) [Row buffering specified, Table buffering is what I get...apparently]
>
>Are you issuing a LOCK command or are you letting VFP put the lock on the record? If you manuall lock a record you will have to UNLOCK it as well.

I count on automatic locking for everything and I count on moving the record pointer or explicit TABLEUPDATE's for updating and unlocking.