Opening a Form in Data Entry Mode

[Montez659]

From all that I have read, opening a form in data entry mode can greatly reduce the resources it takes to open the form (as it doesn't have to load every record in the table, which in the case of a slow network like mine, would create less traffic).

If I can't set the Data Entry property of the form until after it is opened, there is essentially no point to doing this. I suppose I can set the default to data entry and cahnge up some of the other code to programatically set Data Entry to false if someone needs to see the details of an individual record.

I just wanted to check and see if I was missing something before I went ahead and started messing around with it.

 

[Norie]

How are selecting specific records to view?

Why would they manually turn the filter off and stay on the record they had filtered to?

 

[Montez659]

Right now they select the record they want to view from a continuous form/datasheet list of available records to look at. This sets a filter so when they open the form, the specific record that they selected is the only one that shows (because the filter is enabled, it only shows the filtered record which was filtered by record ID).

They do not need to manually turn off the filter to view the record that they selected. however, they do need to manually turn off the filter in order to view any other record. Turning off the filter sets them back to the first record.

 

[Norie]

Why can't they just go back to the continuous form?

That's how I would, and have, set it up in the past.

You can even return to the record they had selected previously.

By the way, I'm think there's a way to do all this without filtering but I can't remember exactly what it is.

I think it might be something to do with DoCmd.GoToRecord...

 

[Montez659]

Unfortunately,the continuous form doesn't show all of the info, so the form that theya re opening is more in-depth and visually more appealing. As far as the DoCmd.GotoRecord, the problem with that seems to be that it goes to a record that is a number in the recordset, not by the id number, which is what I want.

For example, say ID=17. DoCmd.GoTorecord will take you to record #17 and not ID #17.

 

[Norie]

Montez

I know the continuous form doesn't show all the data, that's kind of the general idea.

What I mean is don't allow the user to turn the filter off in the form they've navigated to.

If they want to look at another record they need to close that form and return to the continuous form and select the other record...

Thinking about it more, and doing a little searching, I think it might be something to do with FindFirst/Find and recordsets rather than GoToRecord.^*

Found it, or well an example of what I mean.

It's actually for a continous form with a list of Ingredients.

There's also a simple combobox with A-Z.

Anyway, here it is.

Private Sub Combo15_Change()
Dim rst As DAO.Recordset
 
    If Combo15.ListIndex <> 0 Then
    
        
        Set rst = Me.Recordset
        
        rst.FindFirst "Ingredient Like '" & Combo15.Value & "*'"
        
        Me.Refresh
        
    End If
 
    Set rst = Nothing
 
End Sub

* I actually thought that somehow you could get the record number to go to which is what GoToRecord needs.

 

[Montez659]

That is kind of what I found. It took some slogging through a few examples but I got it figured out. This is what I ended up with in the On Load of the form:

Private Sub Form_Load()

If IsNull(Me.OpenArgs) Then
    Exit Sub
Else

Dim lID As Long
 lID = CInt(Me.OpenArgs)
    Me.DataEntry = False
    With Me.RecordsetClone
      .FindFirst "[visitID] = " & lID
      If .NoMatch Then
        MsgBox "Record Not Found!"
      Else
        Me.Bookmark = .Bookmark
      End If
    End With
End If
End Sub

Sometimes a search engine can be your best friend and sometimes your worst enemy - especially if you are not 100% sure of the terminology that you are searching for.

Also, I wanted to add that going out to the contiuous form each time that they wnated to go to the "next" record would have been highly inconvenient, if not performance hindering. Wouldn't the form have had to load the entire recordset each time the user opened the form, then filter to the correct one? That would have been pretty time consuming on my slow network, which is what I am aiming to fix.

Thanks for the help!

 

[Norie]

Do you mean inconvenient for the user? Perhaps a little but controlling how records are accessed can help avoid errors.

Unless the continuous form taking a long time to load, which it probably shouldn't I can't see any major impact.

I also can't see why you would need to filter to the correct one - I justed posted code that will goto a record based on criteria rather than record number.

 

[Montez659]

Unless the continuous form taking a long time to load, which it probably shouldn't I can't see any major impact.

Any form opening and closing repeatedly is going to requery, so for performance issues (we have a real slow network) this would have an impact.

I also can't see why you would need to filter to the correct one - I justed posted code that will goto a record based on criteria rather than record number.

I was referring to the previous conversation about opening the details form from the continuous form, and not the recent code that you posted. I should have been clearer.

Do you mean inconvenient for the user? Perhaps a little...

Anything that makes the form more inconvenient for the user to use is likely to result in less use of the database. Maybe we disagree here, but I don't work for a bunch of young bucs!

 

[Norie]

Not sure about the requerying thing, especially if the form has no criteria which is what I would assume was the case.

The example code I posted was for a combobox but the basic concept could be used wherever you need to goto a specific record without filtering.

For example you could have a back button on the form that's navigated to .

That button could close the form, open the continuous form and then goto the record that had just been viewed.

In the example