Data Entry Mode Questions

[ions]

Dear Access Experts.

I find DataEntry mode a little mysterious and confusing but I would like to use
it as often as possible since no Records are fetched over the network when
opening a form in this mode.

Below are some questions I had about DataEntry mode.


1) If I am already in DataEntry Mode why does executing Me.DataEntry = True
take me to a new Record? I also noticed it resets the filter and only shows the
1 new record.

If already in DataEntry Mode do you prefer to use Goto NewRecord?


2) I opened my form in DataEntry mode using the following command.

DoCmd.OpenForm "frmAnalyticals", , , , acFormAdd, , Me.cmbSubType

I then later navigated to another record using the below code. Note the record
was created in a completely different session a few days back.

Me.Filter = "AnalyticalHeaderID = " & Me.cmbAnalyticalID
Me.FilterOn = True

After the execution of the above code I was suprised to see that Me.DataEntry is
still True. How can this be?

Is this an MS Access Bug?

3) Suppose my form is bound to a table with 100 records. If in DataEntry mode
and then I execute DataEntry = False does Access fetch all 100 records. Based
on my observations I think so. IT does a complete requery of the form correct?

4) In my current form, I am always navigating to one record using Filters to
keep record fetches to a minimum and using DataEntry mode for new Records.

For example:

Me.Filter = "AnalyticalHeaderID = " & Me.cmbAnalyticalID
Me.FilterOn = True

I want to confirm that I am indeed minimizing network traffic with this coding
style.

I also want to confirm that the above technique works equally well if either
using a JET backend or an SQL server backend with ODBC once I upsize.

Thank you very much.

 

[the_net_2.0]

1) If I am already in DataEntry Mode why does executing Me.DataEntry = True
take me to a new Record? I also noticed it resets the filter and only shows the
1 new record.

If already in DataEntry Mode do you prefer to use Goto NewRecord?

If you're already in data entry mode, you really should be concerned with why the program does that. Eliminate the code or put a conditional in that checks for data entry mode so you don't have to deal with it. For an answer, I have no idea. Never had to deal with it myself.

2) I opened my form in DataEntry mode using the following command.

DoCmd.OpenForm "frmAnalyticals", , , , acFormAdd, , Me.cmbSubType

I then later navigated to another record using the below code. Note the record
was created in a completely different session a few days back.

Me.Filter = "AnalyticalHeaderID = " & Me.cmbAnalyticalID
Me.FilterOn = True

After the execution of the above code I was suprised to see that Me.DataEntry is
still True. How can this be?

Is this an MS Access Bug?

No it's not. Did you look in the props to see that the dataentry was still turned on? This is more complex than you think. If you're really concerned you should run tests to figure it out. For instance:

• manually set the prop and open a form using that ADD code to see if the prop changes in the props list

In general, properties that are manually set in the property sheet for any given form always stay that way, and they take affect when the form is loaded. Some do change in the property sheet when code changes the property and some do not. A good example of mixed behavior here is the following:

*** Set you form filter as OFF and a blank filter in the prop sheet. then open the form from code and apply a filter string in the open command. Close the form and reopen it from the db window. More than likely what you'll see in the prop sheet as a filter string is the same string you specified in code, but the form will not load with this filter on. There's more factors that go into that of course, but testing it yourself will educate you on how all of this work together.

3) Suppose my form is bound to a table with 100 records. If in DataEntry mode
and then I execute DataEntry = False does Access fetch all 100 records. Based
on my observations I think so. IT does a complete requery of the form correct?

It doesn't "fetch" all 100 again. It only loads the records when the form is loaded (I think). Filtering a form doesn't ditch records. It just filters them, hence the prop name. But yes, when a filter is turned off you go right back to record #1. A simple vba one-liner can take you back to the record you were on if need be though. You have to use the "acgoto" argument in the "docmd.gotorecord" command.

4) In my current form, I am always navigating to one record using Filters to
keep record fetches to a minimum and using DataEntry mode for new Records.

For example:

Me.Filter = "AnalyticalHeaderID = " & Me.cmbAnalyticalID
Me.FilterOn = True

I want to confirm that I am indeed minimizing network traffic with this coding
style.

I also want to confirm that the above technique works equally well if either
using a JET backend or an SQL server backend with ODBC once I upsize.

Thank you very much.

Not sure about the ODBC and sql server stuff, but using filters to go to records is not a good idea, IMO. I'm almost positive that using DOCMD.GOTORECORD with a variable as the record number will use far less JET energy than using a filter will. Moreover, it's less risky and Access probably won't complain to you as much.

 

[TexanInParis]

There does seem to be some interesting interaction between DataEntry and FilterOn. I played with it a bit and discovered:

1) Opening a form in DataEntry with a filter does put you in Data Entry mode, but the filter is NOT honored. (You can add a record that doesn't match the filter, and it will still be there.)

2) Setting DataEntry = True even when in DataEntry mode does take you to another new record. If the form was "dirty" when you did this, Access saves the record but shows you only the new record.

3) Defining a Filter and Setting FilterOn = True loads the records that apply to the filter. If DataEntry = True, it will STILL be true after you do this. Personally, I think this is a bug.

4) Setting FilterOn = False removes the filter, resets DataEntry, and loads all records, but this happens only if FilterOn was previously True. It has no effect if FilterOn was False to begin with.

But that begs the question: Why would you want to be in DataEntry mode with a filter defined? It seems to me that runs the risk of the user entering a record that doesn't match the filter and the record "disappears" when saved. That doesn't actually happen in the limited tests I ran, but it still doesn't make sense to me to be in DataEntry with a filter applied.


John Viescas, author
Microsoft Office Access 2010 Inside Out
Microsoft Office Access 2007 Inside Out
Building Microsoft Access Applications
Microsoft Office Access 2003 Inside Out
SQL Queries for Mere Mortals
http://www.viescas.com/
(Paris, France)

 

[ions]

Hi John,

Thanks for responding.

I am happy someone agrees with me that point 3 is a bug. I think of DataEntry as a filter actually. (a special session filter that only allows you to add records)

But that begs the question: Why would you want to be in DataEntry mode with a filter defined? It seems to me that runs the risk of the user entering a record that doesn't match the filter and the record "disappears" when saved. That doesn't actually happen in the limited tests I ran, but it still doesn't make sense to me to be in DataEntry with a filter applied.

John the way access currently behaves is the way I want it to except for point 3which we both agree is a bug.

I find the following point to be very dangerous about flipping DataEntry = True to False. Note you really never have to do this as long as you continue to use filters.

Suppose my form is bound to a table with 100 records. If in DataEntry mode
and then I execute DataEntry = False does Access fetch all 100 records. Based
on my observations I think so. IT does a complete requery of the form correct?