Search results

@Galaxiom Right, I looked at your demo file and see what you're doing there. I like that approach, may come in handy some time. However, it still requires at least some level of user interaction (i.e. the user needs to select certain values in the main form before other values in the subform...

How are you going to determine which Operator value should be stored in the field without a user making a selection at some point?

OK, just call the Project Number After Update event in the Current event of the sub form; Private Sub Form_Current() Project_Number_AfterUpdate End Sub

Simply stating that it didn't work does not help get us any closer to a solution. What, exactly, did you try and what was the result (i.e. an error message, an undesired result, no result at all, etc.). You may also try posting a sanitized copy of your application so we can see the issue directly.

See how I am? I said I wouldn't confuse the issue and then I went and confused the issue;-) If Pat's original example was structured m-m and then you changed that for some reason, then that may be the root of why you are struggling to get the forms to work the way you need. Pat has more time...

Try a requery of the Project Number combo box in the Current event of whichever form it is on. Private Sub Form_Current() Me!cboProject.Requery End Sub

I did see your image but I'm still not clear what you want. You appear to be using a datasheet subform. Are you saying that you want the Operator control on that subform to always display all possible Operators without the users having to expend the effort to click the mouse one time to expand a...

I'm not completely clear on what you're asking, but have you tried using a combo box on the form?

You could use a subquery, or alternatively (but possibly less efficient) you could use DCount.

Here's an alternative example of how to model this based on my previous advice that you have a many-to-many relationship between Crocs and Encounters. To be more specific, in this example, the M2M is between Crocs and Locations, with tblEncounters being the junction table that manages the...

Didn't get a chance to post back a sample file yet but I see that Pat did based on your original table structure. If that example will work for you then I won't post so as not to confuse the issue for you. It looks like my conception of what you would need from a data entry standpoint may have...

Have a look here

Your last statement confirms what I have been saying. A Croc can have multiple Encounters and Encounters can have multiple Crocs. Even though the main purpose of the application may be Crocodile data, the Ecnounters/Locations are still key component of the data. I know that the majority of this...

Do you ever record Croc data at different locations? If so, is it possible that you could see a given Croc at one location, then sometime in the future see that same Croc at a different location, and record a different set of data for that Croc at the new location? Also, is it possible that you...

While that may be a true statement, it's incomplete logic and irrelevant to the design of your database. I'm going to make the assumption that, among other things, you need this database to do the following; 1) Keep track of all of the Crocs that you collect data on at a given Encounter...

So if that happens do you; A. Need to keep the record with the old information that is now no longer valid and enter a new record with the new information. -or- B. Overwrite the existing record with the new information since the old info no longer applies. If it's A, then you need the child...

Does the field FRRotorsReplaced exist in the query?

At the query level you would need a calculated field something like the following (this is air code so could have some typos); IIf(DCount("*", "tblChild", "P_ID=" & [ID])>1,"Multiple Records Pending", Nz(DLookup("Warning", "tblChild", "P_ID=" & [ID]) & " Pending", "No Records Pending))

Then you would need to do something along the lines of what Colin suggested in post #2. You could expand upon this with additional code to allow the user to click on the label, or the subform control, in order to open another form with details for the child record(s)

You could potentially code for it but you would have to code for every control on your form, counting key strokes until some predetermined number of characters had been entered, plus trying to validate the entry, then code the Tab move. However, I agree with Pat. All of this would likely just...