>>Another "quick" question. I've got a grid with 3 columns whose recordsource is a view.
>>Col_1 is text (and what the order is based on)
>>Col_2 is a vendor combobox
>>Col_3 is text.
>>
>>I've designed the combobox to requery the source view after a change/entry into the cell (LostFocus) so the change/addition is reflected in the grid.
>>
>>Well, when I add a new record/row, I enter text in Col_1, fine. I select a vendor from the combo in Col_2, fine, but once I lose focus on that cell, my view is requeried and the items in the grid are resorted based upon the new entry in Col_1, so before the user finishes entering data for the new record, i.e. Col_3's text, the grid's data jumps due to the requery/sort. You then have to find where you left off and return to the appropriate Col_3 cell to complete the entry. I'm afraid this is going to confuse my users.

>Sorry, I cannot understand why you requery the view in Combo.LostFocus. The idea of 'requery' is to retrieve data changes which might happen outside the view, e.g. changes made by another user, or you change data in another form directly in underlying table, etc. When you make selection from the combo, you just change appropriate field in the same view, i.e. you have it already in grid.

Well, my app is far from conventional. ;) A programmer friend had me saving the changes from my comboboxes programmatically back to the original tables since originally I didn't have primary key fields (well, multiple field ones, but not a single one). So since the view couldn't find the original record to update (no key field), we did this via code in the lostfocus method. Thus, we'd need to requery the view so the new data in the original table would be reflected in the view in the grid. Or at least this was my understanding. Very ugly, but it worked at the time.

I've since added primary key fields to everything so maybe you're right and I don't need to requery. Let me go back and try that. Thanks! It's pretty scary what we novices do to "make it work" ;).

Mandy