Fields showing errors

[koncreat]

I have two text boxes that are referencing three other text boxes on a form. The form is a tab form and one is a date field and the other two are part name and part family. When someone picks a date, part name and part family on the first tab on the form the two text boxes on to the side will show what they picked. This helps the user with filling out information on the other tabs as a point of reference.



text box 1: control source = [date_entered]
text box 2: control source = [part_family]&" "&[part_name]


The problem i am having is they are intermittently showing Name?? instead of the values the users picked. If you close out of the database and open it again the problem will sometimes go away. The user may have to do this two or three times to get the error to go away. Not sure if this matters but the database is split into two, one for tables and the other for forms, queries etc.. They both reside on a network drive and users have a shortcut to the non table database.

[Micron]

The split will not be the problem; in fact, it's the recommended way (one FE copy per user). That error is usually due to some reference that cannot be resolved. Closing/reopening the db often clears the ambiguity by resetting something back to the design point, so the solution is likely to get that setting to be re-applied, assuming it is appropriate for the task. However, doing data entry on tabs doesn't sound right. The task isn't clear so I'm only guessing when I say that one main form or a main form with a subform is likely more appropriate. If you're going to stick with the current process, more info is needed, or you could compact/repair your db and post a zipped copy of it here. I may not be able to open it.

[koncreat]

I have attached a cop of the database

[NTC]

as Micron says: one FE copy per user

I think your problem is users sharing the same FE

[Micron]

I don't think that's the issue. I have done it this way before for 2 db's that are used by 20+ users for about 10 years without any problems related to sharing a single FE. While I don't recommend it and would do things differently now, I did it to avoid distribution problems due to not knowing a distribution method that was better than that of my predecessor, given the network and specific user issues. As I mentioned, the error is usually one of failing to resolve a reference or function call from a control.

koncreat:
- the db is pretty much useless without the tables, as the links themselves are not sufficient. While they might appear to be there, they are not for us.
- saving a smaller version with just the tables, queries, reports and forms needed for the issue at hand is probably better
- making that version a 2007 version will get you more forum members who are able to open it
- providing some idea of what form to open would help. You've outlined your problem without providing any clue as to where to start.

I can't really say how far I'd get with a 2010 version since not having any tables is a significant barrier in itself.

[koncreat]

My apologies i uploaded the wrong file.

[Missinglinq]

You have close to two dozens forms...it would help if we knew which one you're having trouble with!

[Micron]

Using the switchboard form and opening for plant 1 I see the controls in question (I think). They seem to be combos, not textboxes as reported. I think you'll have to reproduce the error on your end and let us know exactly what the sequence of events is that causes it. It might be a result of selecting one tab or another and then populating one of the many, many fields somewhere that causes the error. If I had more time right now, I'd look a the row and control sources for the combos to see if I could spot what might be changing, but I have to go for now. One thing that must really bug your users is how selecting Sort Results tab makes it impossible to go back to any of the other tabs. I have to close the form and deal with warnings about not being able to save the record.

[koncreat]

The issue happens when a user opens the form, yes you opened the correct one, and will go away if you close and open it again. It may take more than one time of closing then opening again but it will go away.

[Micron]

Well, I opened/closed it 10 times with no such error that I could see. Still think you need to be more specific - unless I missed something, we don't even know which controls you get the error in. No point in looking at a dozen control record (or row source) properties without knowing. Aside from the fact that your control and field names are the same, I have nothing else to add at this point. I NEVER have these with the same names because Access does sometimes generate that error because of ambiguity. When that happens it's because it can't decide on which you're referring to. You might want to check this out https://access-programmers.co.uk/for...d.php?t=225837

I see that you're designing for a very specific screen size because you're removed all scroll bars. Large parts of the forms don't fit my screen. That's why I have to close the form when I go on that tab - all the other tabs disappear from view. I think you're asking for future trouble there.

[koncreat]

When you open the switchboard and then either the plant 1 or plant 2 form on the right side are two text boxes, test482 and text484. Text482's control source is date_entered. Text484's control source is two fields combined, part_family and part_name. The control sources are combo boxes. The problem has been that text482 and 484 will show Name?? instead of the information their respective control sources show.

[Micron]

So here's some things that don't look right to me, an non-macro user.
- You're requerying the form for no reason as far as I can see. If it's to show the effect of changing the label caption, use Repaint.
- nitpicking, but Text482's control source is not "date_entered" it's "=date_entered". Since that's a field in the form's record source, the = is not required and may actually be the cause of the problem if the requery is not.
If making these changes has no effect, I can only suggest putting the macro in break mode (if that's possible for an embedded macro) and stepping through it to see if you can spot which command causes the error. If the problem is that the control source for either of these controls is not being deciphered before the form is finished loading because of network speed issues, that could be why I cannot reproduce the problem on my laptop. Hopefully if it's a network speed issue, making those changes will solve the issue.

[HiTechCoach]

FIRST, the control name and the field names are the same for Date_Entered. It is best to rename the text box control to be something like txtDate_Entered. Change Text482 to have a control source of =[txtDate_Entered]. Same for the other controls. This removes any ambiguity for Access when trying to figure out which object is referenced.

If this were a database I was supporting this would be my TOP priority to fix.


Second, the front end should be local on the PC. Shared front end databases that are not compiled (.accdb/.mdb ) can cause issues. Also network latency can be an issue. Having the front end local ALWAYS helps eliminate potential problems. A compiled front end (.accde/.mde) also helps. Even better is to use runtime mode. This is easily done be renaming the front end (.accdb/.accde) to .accdr.

After fixing the control names you may be fixed. I would recommend as a test try renaming the .front end to .accdr and have everyone use it.

Let us know if this helps.

[koncreat]

So this screen shot shows the error i am getting intermittently. This FE is running locally on my PC.

[koncreat]

This file has the screen shot