Event timing?

Back to an earlier question. Yes I am getting different behavior whether I get to the form via the list form or if I open the form straight from the nav menu. You can also see the difference in the record count box at the bottom of the screen. When I open from Nav I have 40 plus records. When I open from the macro from the other form it shows 1 of 1. So that makes some sense that it can't find it (although it still can detect the duplicate, it just can't go there). So now I am reconsidering the user interface. maybe instead of launching the listing form I will launch a button form so the user can deliberately go to add a new record or to go to add to an existing record. I can still do the check for unique value in the new record form and send the user back to the landing page with message if they type in an existing RefNum. You know, it helps me to think about it when I type this stuff out. I'll keep you posted.

Regards
 
@gakiss2
I've not read the entire thread so let me know if I've missed something.
I opened your database, clicked RefNum on the main form and then add new record on the second form.
I deliberately used an existing RefNum and of course it allowed that as it's not the PK field and you've indexed it to allow duplicates...even though you don't want dupes.
So I went into the table, removed the duplicate record together with the record with a null RefNum. I then changed the PK field to RefNum.

On repeating my previous actions, as soon as I enter a duplicate RefNum in a new record, Access does exactly what it should and shows your before update code message that 'a record with that value already exists'. On clicking ok, you are returned to the existing record due to your before update code. No new record is created.

Personally I would instead show the message then clear the RefNum field so a new value can be entered instead.

Does that help or am I missing the point?

As a separate issue you have several attachment fields which are generally considered a bad idea as they cause file size to bloat significantly. Recommend you store the files externally and instead save the file paths in your database
 
Hi,

Please see attached copy of your db. Hope it's what you want.
 

Attachments

The DoCmd.FindRecord doesn't work, because the form is filtered so the record to find isn't available!
 
Isla Dogs. point somewhat missed in that I am looking for a different form behavior. The db had been faithfully showing the duplicate value message. Before that I had tried setting RefNum as the PK. The code has evolved since then but I first made RefNum the PK, even before the code to show the duplicate value message was put in. Nothing happened immediately when the duplicate value was put in RefNum. The user could continue to enter more data into the record until the db went to save the record and then the native Access message for duplicate value would pop up. For me that was not a great solution. Lots of time wasted filling in data that is lost, frustrating, etc. etc. So next was the code I found which gives the notification of the duplicate value. That worked, great. So it was after that when I had the great idea ' Why not have the db move to the record which has the RefNum they had typed in which was the duplicate?' My logic is that, other than a typo, the main reason a user would put in a duplicate RefNum would be because they had additional data to put into that record. And I sort of got that to work with DoCmd.FindRecord ctlRefNum.Text. At some point along the way to this point I had to take out "no duplicates" for RefNum to make the code work. I justified to myself that the code would take care of preventing duplicates. So then at this point all is working perfect from a user point of view. If the user typed in an existing RefNum the form would jump to the record that had that RefNum and they could add data to the record as they please. The problem is that this method is not exactly preventing duplicates, it is creating an additional record with that RefNum which contains only the fields filled in up the point that the before update fired and detected the duplicate. Mostly these records have only a few fields as the RefNum field is fairly 'early' on the page/form. I tried adding code to get rid of the unwanted records but if I did that before the DoCmd.FindRecord then the fact that the record was deleted caused the DoCmd.FindRecord to not find the record. If I tried to delete last record after the Db moved to the reocord I wanted then the, naturally, the form would move to that record thus defeating the code that moved to the record I wanted. So I started the discussion thinking I just needed help know which event to use to get rid of the unwanted 'near empty' record. Since then the discussion has evolved to other possible solutions. I appreciate any feedback / advice / philosophical punditry that you have to offer.
 
JHB: yes, I figured that out later yesterday evening. I use a open form macro command with a where clause that is based on a control on a previous form to get to the record I want. Is there a way I can still do that but then have the form 'recognize' all the records like it does when the form is opened from the Nav? I'd like to keep the process of starting with the list of reocords so the user can choose the one she would like to go to.

I am considering other methods for the user to get to a Add Form mode. I think I'll have more control of behavior that way. I'll probably build what I call a 'button form', just buttons to move from one form to another.

thanks for the input
 
Hi gakiss
Yes I realised most of that.
What I was saying was that by using RefNum as the PK key, NO NEW RECORD is created

Good luck with your project
 
DBguy Seems to work perfectly now. I'll test a bit to make sure but Thank You very much.
 
Hi,

You’re welcome. Glad we could help. Good luck with your project.
 
DBguy: Being new to the blog/forum concept, am I supposed to do something to close out the discussion at this point?
 
Hi,

At the top of this thread, there’s a drop down labeled “Thread Tools.”
 

Users who are viewing this thread

Back
Top Bottom