Greetings All,
I thought to share a debugging suggestion based on a finding just now, and ones I can recall as well.
In my Form Open event, I call to the business logic which the Requery button also is connected to. This functionality empties the FE temp table, then issues a pair of DAO queries to download records from the SQL BE to the FE temp table.
Suddenly doing so would totally crash Access and the box would come up offering to clean up the DB and reopen. hhhhmmmm.....
I went through the process of manually running each query interactively rather than through code. That means commenting the Execute of the queries, and also the deletion of the DAO.Querydef objects.
Then running one query interactively told me "You dummy, you have one more column selected than is in the FE temp table." and indeed I had forgotten to update the FE temp table schema with a column I had realized got missed.
"Why O why, MS, could you not handle that error gracefully via VBA automation!?!?!"
Likewise, I have code which populates the ODBC connection string into Linked Table objects. Suddenly that started crashing Access the same way. Turns out, I had linked a test table which I later deleted on the server. Finding no table to match the Linked Table object, Access decided best to crash on the spot. I deleted the Linked Table object, and that cleared up the crashing that time.
So, good as error trapping / handling is, there ARE times that MS will decide to just crash anyway and leave you scratching your head as to what got into Access. "You have been warned!" (This message will be destructed by an organization headquartered in Redmond, WA! )
I thought to share a debugging suggestion based on a finding just now, and ones I can recall as well.
In my Form Open event, I call to the business logic which the Requery button also is connected to. This functionality empties the FE temp table, then issues a pair of DAO queries to download records from the SQL BE to the FE temp table.
Suddenly doing so would totally crash Access and the box would come up offering to clean up the DB and reopen. hhhhmmmm.....
I went through the process of manually running each query interactively rather than through code. That means commenting the Execute of the queries, and also the deletion of the DAO.Querydef objects.
Then running one query interactively told me "You dummy, you have one more column selected than is in the FE temp table." and indeed I had forgotten to update the FE temp table schema with a column I had realized got missed.
"Why O why, MS, could you not handle that error gracefully via VBA automation!?!?!"
Likewise, I have code which populates the ODBC connection string into Linked Table objects. Suddenly that started crashing Access the same way. Turns out, I had linked a test table which I later deleted on the server. Finding no table to match the Linked Table object, Access decided best to crash on the spot. I deleted the Linked Table object, and that cleared up the crashing that time.
So, good as error trapping / handling is, there ARE times that MS will decide to just crash anyway and leave you scratching your head as to what got into Access. "You have been warned!" (This message will be destructed by an organization headquartered in Redmond, WA! )