Rx_
Nothing In Moderation
- Local time
- Yesterday, 23:42
- Joined
- Oct 22, 2009
- Messages
- 2,803
Reporting trend in Access 2013 that creates a catastrophic App Crash (AppCrash) in the VB Module. It leaves the Locking DB open. There is no error trap for an AppCrash.
Around 10 Weeks ago, a very small group of Access Programmers converted a 90 MB Front-End (SQL Server Back End) from Access 2010 to Access 2013.
We experienced a small rash of AppCrash from Windows when opening a form.
They seemed somewhat random as if a file might have become corrupt.
This is a Report for Trending Analysis of the AppCrash so that anyone following the migration into Access 2013 can read and hopefully add their observations.
Observation 1:
When migrating from Access 2010 (latest SP) to Access 2013 (Latest SP) multiple developers found that one could stay in Access 2010 while the other developed in Access 2013.
This is mentioned because in the past versions, a blank DB copy was created in the new version. Then a migrate all objects from the old version was used. This process had two advantages:
1. There were less problems than just opening the old version with the new version. Our projects are based on Regulations. The vba rule codes are much larger than normal Access projects. For example: values on other forms of the application affect the drop-down, listbox, and logical conditions on other forms.
2. The Project has a better compact and re-indexing. Compact and Repair can take a front-end down to 92 MB. When opening a blank Access 2013 and importing all objects, the project compressed down to 63 MB.
Note: Opening the Access 2013 Project back up in 2010 did not re-bloat the project.
Observation 1: As development continued only on Access 2013 local hard drive, the Access 2010 was used for Testing and developing SQL Server back end.
After a week of development with incremental version saves, the AppCrash appeared on Access 2013 developer workstation. When a copy of the front-end was opened on the Access 2010 workstation - there was no AppCrash.
On a 3rd workstation with access 2013, the AppCrash was present. It was related to a specific form among a group of specific objects.
Solution 1:
Many years ago, this happened to me and Bob Larson made a suggestion that worked.
The developer was asked to create a new Access 2013 Application and migrate into to it the 3 forms that had the most inter-action.
They were made to manually re-create the objects in question, copy all of the code behind the old object back behind the new objects. Delete the old objects and code. Then rename the new objects with the same name as the deleted object. VERY IMPORTANT: Compact and Repair (This failed twice with out this).
Then- the original application forms were deleted VERY IMPORTANT - Compact and Repair. Followed by importing back the forms from the new blank copy. Then Debug - Compile Database
Shocker 1: There was an error not seen before. A reference to a control that now needed a more specific reference of value.
This lead us to believe there might be some subtle differences in the VBA reference for Access 2013.
Result 1: The Appcrash went away.
Observation 2
On this 70 MB Front-End, I worked solo in Access 2013.
This form is self contained. For test purpose it has a if-then statement to determine if it was called with openarg - if not an input box is used so the developer can enter an ID or use the default.
Yesterday, this was opened and closed over 100 times.
During the process, a group of two dropdown box and four text box were copied and pasted to a different part of the form. The objects were renamed. The two drop-down were converted into Text Boxes.
This was done as a prototype with the intent of changing the recordsource behind the copied objects the next morning.
This was used for hours, opening, arranging, renaming with out incident. Then it was closed for the evening.
The next morning the project front-end was copied and pasted for version control and opened. The form open created an APPCRASH.
Yesterday's saved copy, the one opened and closed all afternoon was opened and had the AppCrash.
Going back to the version before the Copy and Past control, no AppCrash.
Observation 2:
This incident reminded me that the Observation 1 above also had a copy / paste control on that form.
This incident also reminded me that the control Bob Larson suspected was corrupt and suggested I remake manually was a copy and replace (This might have been Access 2003, long time ago). Of interest, that control did not corrupt until around 3 weeks later.
Solution 2
As a personal policy, never copy / paste a control.
This AppCrash is so scary as a developer, the policy of never copy/paste a control will even apply to Labels.
Around 10 Weeks ago, a very small group of Access Programmers converted a 90 MB Front-End (SQL Server Back End) from Access 2010 to Access 2013.
We experienced a small rash of AppCrash from Windows when opening a form.
They seemed somewhat random as if a file might have become corrupt.
This is a Report for Trending Analysis of the AppCrash so that anyone following the migration into Access 2013 can read and hopefully add their observations.
Observation 1:
When migrating from Access 2010 (latest SP) to Access 2013 (Latest SP) multiple developers found that one could stay in Access 2010 while the other developed in Access 2013.
This is mentioned because in the past versions, a blank DB copy was created in the new version. Then a migrate all objects from the old version was used. This process had two advantages:
1. There were less problems than just opening the old version with the new version. Our projects are based on Regulations. The vba rule codes are much larger than normal Access projects. For example: values on other forms of the application affect the drop-down, listbox, and logical conditions on other forms.
2. The Project has a better compact and re-indexing. Compact and Repair can take a front-end down to 92 MB. When opening a blank Access 2013 and importing all objects, the project compressed down to 63 MB.
Note: Opening the Access 2013 Project back up in 2010 did not re-bloat the project.
Observation 1: As development continued only on Access 2013 local hard drive, the Access 2010 was used for Testing and developing SQL Server back end.
After a week of development with incremental version saves, the AppCrash appeared on Access 2013 developer workstation. When a copy of the front-end was opened on the Access 2010 workstation - there was no AppCrash.
On a 3rd workstation with access 2013, the AppCrash was present. It was related to a specific form among a group of specific objects.
Solution 1:
Many years ago, this happened to me and Bob Larson made a suggestion that worked.
The developer was asked to create a new Access 2013 Application and migrate into to it the 3 forms that had the most inter-action.
They were made to manually re-create the objects in question, copy all of the code behind the old object back behind the new objects. Delete the old objects and code. Then rename the new objects with the same name as the deleted object. VERY IMPORTANT: Compact and Repair (This failed twice with out this).
Then- the original application forms were deleted VERY IMPORTANT - Compact and Repair. Followed by importing back the forms from the new blank copy. Then Debug - Compile Database
Shocker 1: There was an error not seen before. A reference to a control that now needed a more specific reference of value.
This lead us to believe there might be some subtle differences in the VBA reference for Access 2013.
Result 1: The Appcrash went away.
Observation 2
On this 70 MB Front-End, I worked solo in Access 2013.
This form is self contained. For test purpose it has a if-then statement to determine if it was called with openarg - if not an input box is used so the developer can enter an ID or use the default.
Yesterday, this was opened and closed over 100 times.
During the process, a group of two dropdown box and four text box were copied and pasted to a different part of the form. The objects were renamed. The two drop-down were converted into Text Boxes.
This was done as a prototype with the intent of changing the recordsource behind the copied objects the next morning.
This was used for hours, opening, arranging, renaming with out incident. Then it was closed for the evening.
The next morning the project front-end was copied and pasted for version control and opened. The form open created an APPCRASH.
Yesterday's saved copy, the one opened and closed all afternoon was opened and had the AppCrash.
Going back to the version before the Copy and Past control, no AppCrash.
Observation 2:
This incident reminded me that the Observation 1 above also had a copy / paste control on that form.
This incident also reminded me that the control Bob Larson suspected was corrupt and suggested I remake manually was a copy and replace (This might have been Access 2003, long time ago). Of interest, that control did not corrupt until around 3 weeks later.
Solution 2
As a personal policy, never copy / paste a control.
This AppCrash is so scary as a developer, the policy of never copy/paste a control will even apply to Labels.
