J
John Kounis
I have an order form with customer information on it, as well as a subform
with order items. Both are based on SQL Server views, and the forms are in a
Microsoft Access .adp front end. The primary key for the view on which the
main form is based is "OrderNumber". The primary key for the subform view is
"ItemID", but "OrderNumber" is also a non-unique key. The main form is in
"Single Form View" and I've tried both "Continuous Forms" and "Datasheet"
for the subform.
The problem I'm having is that after several inserts/edits//deletes of rows
on the subform, Access seems to lose track of how many rows there are on the
subform. For example, if there are 9 rows visible, I can only select the
first 5 rows of the form. The cursor simply won't move to a field on rows 6
through 9; they simply won't receive focus. (Note; Row 10 will receive
focus, though, so I can add new records)
Further investigation reveals that, when this problem occurs, the value of
Me.RecordSet.RecordCount is wrong. In this case, with 9 rows visible,
Me.RecordSet.RecordCount was 5 (WRONG), but Me.RecordSetClone.RecordCount
was 9 (CORRECT).
I am not familiar with any scenario where Me.RecordSet.RecordCount should be
different from Me.RecordSetClone.RecordCount, so it seems like a bug. If I
type Control-Break and start examining data when this occurs, Access
inevitably crashes with one of the following messages:
Using Access 2000 on Windows 2000:
The instruction at 0x650a4126 referenced memory at 0x02130003. The memory
could not be "read".
Click OK to terminate the program
Click CANCEL to debug the program
Using Access 2003 on a Win XP Pro:
Access has encountered a problem and needs to close.
I hesitate to say this is a bug in Access, because every time I've suspected
a bug in off-the-shelf software in the past, I've eventually tracked it down
to my own problem, and not a problem with my software. However, this really
seems to indicate an Access bug. Has anyone heard of this problem before?
Any ideas how to work around it?
Thanks!
John Kounis
(email address is my first name - at - pilotgetaways.com)
with order items. Both are based on SQL Server views, and the forms are in a
Microsoft Access .adp front end. The primary key for the view on which the
main form is based is "OrderNumber". The primary key for the subform view is
"ItemID", but "OrderNumber" is also a non-unique key. The main form is in
"Single Form View" and I've tried both "Continuous Forms" and "Datasheet"
for the subform.
The problem I'm having is that after several inserts/edits//deletes of rows
on the subform, Access seems to lose track of how many rows there are on the
subform. For example, if there are 9 rows visible, I can only select the
first 5 rows of the form. The cursor simply won't move to a field on rows 6
through 9; they simply won't receive focus. (Note; Row 10 will receive
focus, though, so I can add new records)
Further investigation reveals that, when this problem occurs, the value of
Me.RecordSet.RecordCount is wrong. In this case, with 9 rows visible,
Me.RecordSet.RecordCount was 5 (WRONG), but Me.RecordSetClone.RecordCount
was 9 (CORRECT).
I am not familiar with any scenario where Me.RecordSet.RecordCount should be
different from Me.RecordSetClone.RecordCount, so it seems like a bug. If I
type Control-Break and start examining data when this occurs, Access
inevitably crashes with one of the following messages:
Using Access 2000 on Windows 2000:
The instruction at 0x650a4126 referenced memory at 0x02130003. The memory
could not be "read".
Click OK to terminate the program
Click CANCEL to debug the program
Using Access 2003 on a Win XP Pro:
Access has encountered a problem and needs to close.
I hesitate to say this is a bug in Access, because every time I've suspected
a bug in off-the-shelf software in the past, I've eventually tracked it down
to my own problem, and not a problem with my software. However, this really
seems to indicate an Access bug. Has anyone heard of this problem before?
Any ideas how to work around it?
Thanks!
John Kounis
(email address is my first name - at - pilotgetaways.com)