Description:
When pulling out rows using the Query Browser, and then attempting to hand edit fields or rows 'in situ' in the lower QueryTab window, very often you will experience 'Access Violation' Errors appearing in the status bar at the very bottom.
How to repeat:
Open a db with a 'basic' query to return some rows to the querytab window (eg. SELECT * FROM mytable t; or something equally basic, where the querytab window will be able to locate the underlying records distinctly, and thus be able to 'Edit' them).
Select a field.
If the 'Edit' button at the bottom is illuminated, press it (if it isn't, go make another query which has no ambiguity about the rows returned).
Double-click on the field to highlight it for editing
Make some changes
Click on a different field or row (to make the 'Apply/Discard Changes' buttons illuminate at the bottom).
Press 'Apply Changes'.
Rinse and repeat, changing (deleting) a few rows, or making field edits, sometimes in groups (before pressing Apply) or individually - makes no difference. Eventually, you'll see the 'Access Violation errors' appear in the bottom status bar.
Press the C (in a circle) button to the left of the error, to 'clear' the error display. Notice that from here on, the querytab can no longer be entirely trusted - deleted rows still appear, and field-edits seem to have 'taken' - but it's not always so. The only way to be sure, is to run the query again, get a new result-set, and carry on editing until the next Access Violation error appears.
Suggested fix:
It seems possible (if you are brave) that you can assume the following after an 'Access Violation' error:
1 - the edit DID probably happen.
2 - deleted rows will appear to remain on display as if they had not been deleted, but are in fact gone.
3 - altered fields will generally reflect their updated position, and are usually still ok to trust. Can't guarantee this, though... YMMV.
4 - from here on in, all future attempts to 'edit' will always cause another Access Violation error, but again, they do actually seem to be working.
I would therefore guess this is a problem related to just the DISPLAY of the recordset in the QueryTab window, not necessarily anything to do with the actual UPDATING of the underlying recordset itself (which seems to work ok).
However, it is a pain to have to keep re-querying (especially if it's a big slow query), in order to be sure that the changes you're making ARE indeed the changes which are actually happening.
