Suppressing Extra Row at Bottom of Continuous Form

[JoeM]

Hello. Long-time user of Access here, and I have encountered a quirk I have never seen before.

I have set-up a Continuous Form from a query where users can enter in values to pre-existing records. I do not want the user to be able to add or delete any records here, simply update existing records that they arrive at from a Selection Form I have created. So I have gone into the Properties of the Form and set the following Property values on my Form:
- Data Entry: No


- Allow Additions: No
- Allow Deletions: No
- Allow Edits: Yes
- Record Selectors: No
- Navigation Buttons: No

It lists all the records (from the Detail section), but for some reason it also shows a blank row underneath the last record. It allows the user to start typing into this blank record, though it errors out when they try to leave it, as the user cannot enter in the key fields for a new record.

It is good that they cannot enter/save new records, because I do not want to allow that, but I cannot figure out why it is displaying this blank record at the bottom, and want to suppress/hide it. Usually, setting the Properties to the values I have shown above do the trick, but for some reason it does not appear to be working.

Has anyone seen anything like this, or know how to hide this "false" blank record? Thanks.
BTW, I am using Access 2007.

[June7]

Cannot replicate the issue. Want to provide your db for analysis? Follow instructions at bottom of my post.

[Missinglinq]

Because of the fact that

• The AllowAdditions Property is set to No
• But the Access Gnomes are still allowing A New Record to be initiated

my guess would be that the Form in question is being Opened using code similar to

DoCmd.OpenForm "ContinuousFormName", , , , acFormEdit

or the Macro equivelent, thinking that the acFormEdit argument would only allow the editing of Records. The problem with this assumption is two-fold:

1. acFormEdit allows for the Editing of Existing Records and the Adding of New Records
2. acFormEdit tells Access to ignore the AllowAdditions and AllowEdits Properties of the Form being Opened as set in that Form's Properties Pane!

To allow the AllowAdditions and AllowEdits Properties of the Form being Opened to act as set in the Properties Pane, i.e.

• AllowAdditions set to No
• AllowEdits set to No

you need to Open the Form with code like this

DoCmd.OpenForm "ContinuousFormName", , , , acFormPropertySettings

The acFormPropertySettings argument tells Access to respect the Form's Properties as set in the Properties Pane.

Sorry, but I have no idea how to accomplish this using a Macro, or even if it can be accomplished using a Macro! That's one of the problems with Macros, they're too limited/rigid in what they can and cannot do, which is why most experienced Access developers do not use them!

Linq ;0)>

[JoeM]

you need to Open the Form with code like this

DoCmd.OpenForm "ContinuousFormName", , , , acFormPropertySettings

Thanks, that did the trick. I figured (hoped) it was something fairly basic like that.

Sorry, but I have no idea how to accomplish this using a Macro, or even if it can be accomplished using a Macro! That's one of the problems with Macros, they're too limited/rigid in what they can and cannot do, which is why most experienced Access developers do not use them!

Linq ;0)>

I am not using a Macro, I am using VBA, so your answer gave me what I needed. I know what you are saying about Macros, I rarely use them myself because of their rigidity. I have been programming in Access VBA for about 10 years now.

Thanks for the help!

[Missinglinq]

Glad you got it working!

I think just before answering your question I was working on a problem for someone else who was using Macros, and still had that on my mind! VBA is the only way to go, for serious development.

Linq ;0)>

[JoeM]

VBA is the only way to go, for serious development.

I wholeleartedly agree!

[June7]

Great insight on the issue, Linq. I, of course, agree about VBA. I use macros only if I absolutely have to and so far that has happened twice. But I have never created a web database. I understand that macros might be required for that, especially if using Sharepoint.

[Missinglinq]

...I understand that macros might be required for that, especially if using Sharepoint.

Have no clue and don't really care! Security-wise, as you probably know, Access is a mess! And the idea of taking an Access app and putting in on the web sounds like a surefire path to disaster!

I keep my ears open, of course, always willing to learn, but in doing this kind of thing, here and on other forums, 8 hours a day, 7 days a week for past 6 years, I've really seen very few threads relating to that kind of thing! And if you're right, and they require heavy Macro usage, I surely won't go down that trail!



Linq ;0)>