Let's look a little more closely at the Recordset object's Save method. Any open Recordset can be saved—not just ones created in memory. Once a Recordset is saved, it can be reopened by referencing the filename in the Open method.
The following example opens a Recordset from the filename specified by the CommonDialog control. The Open method uses the filename as the Source argument—not as the Connection argument. While it's possible to create a Connection object and set the Connection string to "File Name=" & .Filename, the simple Open method expects the syntax shown here:
With CommonDialog1 .ShowOpen Set rs = New Recordset rs.Open .FileName Debug.Print rs.RecordCount End With
If the Filter property is in effect for the Recordset, only the rows that qualify based on the Filter criteria are saved. (I discuss the Filter property in Chapter 7.) If the Recordset is hierarchical, the current child Recordset and its children are saved, but not the parent Recordset. If Recordset membership population is not complete, the Save method blocks until the asynchronous population is complete. This ensures that all member rows are included.
An interesting issue:When using server-side cursors (adUseServer), the Save method saves all rows for the statement, regardless of the MaxRecords setting specified for the Recordset.
Once the Recordset is opened against a file, the Save method resaves the Recordset to the same file by default. If you save to a new filename, the original file is left open. While the Recordset is open, other users have read (only) access to the file.
After using the Save method, the current row pointer is positioned to the first row of the Recordset. At this point, you can continue to work on the Recordset—it remains open until you use the Close method or set the Recordset to Nothing.
If you try to use the Save method in an Internet Explorer Web page, remember that, for security reasons, the Save method is only allowed in zones with "low" and "custom" security settings. For a more detailed explanation of security issues, see the white paper titled, "Security Issues in the Microsoft Internet Explorer," at http://www.microsoft.com/data/techmat.htm.