Question : ADP, Computer Idle Form Reverts?

I have an Microsoft Access 2003 ADP, which uses a bound "main" form with several bound continuous-style subforms. They all utilize disconnected Recordsets via a helper class.

Several users have noticed the same strange behavior: they add/edit a record in the continuous subform, they leave the record (committing the edit to the Recordset), they lock the computer (Ctrl+Alt+Del), they unlock the computer, they go back to the form, after about 5 seconds it flickers and revert to the original unedited state.

I've been able to reproduce this following the steps above, further, after making a change in my form, bound to a disconnected Recordset, I went to SQL Server and changed a value. After the lock/unlock computer routine, the form flickers and refreshes, and the NEW value I just entered in SQL Server appears.

It's as if after about 5 seconds, my disconnected Recordset is reconnecting (on it's own) and requerying the Recordset.

I realize I'm not giving a lot of information here, but has anyone encountered an issue with disconnected Recordsets reconnecting and requerying? Or at least have an ideas of where I could start debugging?

Here's how I'm creating the disconnected Recordset.

Code Snippet:

         
           
             1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:

           
           
             Dim cnn                 As ADODB.Connection
  Dim stmTest             As ADODB.Stream
  
  Set cnn = New ADODB.Connection
  cnn.Open Application.CurrentProject.AccessConnection.ConnectionString
  
   ' Create recordset and disconnect it.
  Set mrsTest = New ADODB.Recordset
  mrsTest.CursorLocation = adUseClient
  mrsTest.Open "SELECT * FROM [tblChild] WHERE ParentID = 1" _
      , cnn _
      , adOpenStatic, adLockBatchOptimistic
  Set mrsTest.ActiveConnection = Nothing
  
  cnn.Close
  Set cnn = Nothing
    
  ' Copy recordset to stream in memory.
  Set stmTest = New ADODB.Stream
  stmTest.Open
  mrsTest.Save stmTest, adPersistADTG
  
  ' Bind form to disconnected recordset.
  Set Me.Recordset = mrsTest
  
  ' Open a copy of the recordset from the stream.
  Set mrsTest = New ADODB.Recordset
  stmTest.Position = 0
  mrsTest.Open stmTest

           
         

Open in New Window

Select All

Answer : ADP, Computer Idle Form Reverts?

Yes, I was able to reproduce this, and indeed this is very interesting. I bet that nobody will be able to explain this, including Microsoft; the only explanation I can offer is this:

Access is simply not supposed to be used that way. Access OLEDB provider is somewhat different from the "pure" ADO, and you can't do with it everything you can do with pure ADO recordset. For example, you can't use server-based cursors. Even though it's supposed to be close, I'm sure Microsoft did not test all possible scenarios, such as yours, when you not only make recordset disconnected, but also clone it to stream and then recreate from stream. So the bottom line is, the results of such manipulations are simply unpredictable. Access is expecting to be connected to the live database, because it's so designed, and perhaps when the session is unlocked, it decides that something went terribly wrong, and simply reconnects. Especially it might make such conclusion because that's what is initially specified in the form's recordsource (i.e. what you see in design mode).

And there's good reason why Microsoft did not test all that. That reason is that Access is rapid application development tool, and it's supposed to be used in pretty straightforward manner: make bound form and use it. Don't try to manipulate the data, tell Access where the data is, and allow it to manipulate it by itself. Don't twist its arms by forcing your own recordset on the form, allow the form to build its recordset by itself. In order to be productive with Access, adapt to Access-oriented thinking. If you want full control, if you want to manipulate the data by yourself, then that's what Visual Studio is for. Which is, by the way, major limitation of Access ADP, and the main reason why Microsoft might indeed say "move away from ADP", that LSMConsulting mentioned (even though I bet $10 that Microsoft in fact absolutely never said that; there were rumors after Office 2007 release, but nothing was ever confirmed or denied. As I understand, there's no consensus about that in Microsoft itself).

From my experience, usually super-sophisticated solutions are born when there's not yet full appreciation of the tool, and developer is trying to implement the thinking from another tool he is more familiar with - i.e. all these tricks with juggling the data between recordsets and streams, you developed them with some other tool, didn't you. If you tell what is the final objective of all this effort, maybe we will figure out something more natural for ADP.