Tech Support Guy banner

Access 97: Simple Subforms Question

1581 Views 15 Replies 3 Participants Last post by  Gram123
Hi,

I have to create a very simple database to gauge the instances of Manufacturing Faults in new vehicles, and maybe it's just cos I haven't done it for a while (or maybe cos I rely on you guys too much), but I've got a little lost.

The db consists (currently) of a Data Entry form containing 4 fields: Date, Ship Number, Chassis Number and Model; and a subform with a linked Chassis Number field, plus fields for Part and Fault (so I could have say, "CD player" as an entry in Part and "Wrong Spec" in Fault). I've based the Data Entry form on one table and the subform on another.

Originally I had the Chassis Number as the Primary Key in the main table. I entered a record, went to the subform and entered a part and fault, the Chassis popping up just as required, but then when I tried to enter another part on the same Chassis, I got the duplicate records error.
Figuring that this was because of the Primary Key, I added an Auto-number field to the main table and made this the Primary Key. I changed the properties of Chassis Number to allow duplicates and tried again to enter a record.

Now the Chassis does not pop up in the subform, and I get an error saying:
The LinkMaster fields property setting has produced this error 'Ambiguous name detected: Back_Click'

I understand that the Master and Child fields are the link between the form and subform. I guess Back_Click is part of the code it generates automatically. But I don't understand what to do about it. I tried creating a relationship between the two tables but the duplicate error came up again.

Any help?

Gram
Status
Not open for further replies.
1 - 16 of 16 Posts
I think I would create the following tables:

tblAutos
ChassisNumber - Primary Key, Unique
Model
ShipNumber
Date

tblParts
PartNumber - Primary Key, Unique
PartName
PartDesc

tblFaults
FaultTypeID - Primary Key, Unique
FaultDesc

tblFaultsFound
FaultID - Autonumber type, Primary Key
ChassisNumber - Foreign Key to tblAutos
PartNumber - Foreign Key to tblParts
FaultTypeID - (This could point to a table of possible faults)

I would set a relationships between the tables.

Hope that helps...
See less See more
Thanks th3856, but that sounds like overcomplicating things.

I have included a Models table, a Parts table and a Faults table, but these are only lists and are used for combo boxes on the main form. As such, they only have one field.
I want to keep the data to just two tables if possible, but I haven't done much work with subforms, so I'm not sure how to relate it to the main form (table) without getting the error messages.
I have basic relationships between the tables, but haven't got a primary key in the subform table - could this be the cause of my problem?

Gram
...I'm still waiting for that promised beer.

Don't confuse data-integrity/normalization links (which enforce rules between tables, and by the way if you are actually using text lookups instead of ID-number-tied-to-a-modifiable-text-field lookups, make sure you're using referential integrity and cascades, but that's another question) and master form / subform links.

You have on the property sheet of the master form's subform control (I know this sounds like garbage, but I can't help it--there's a difference between the frame holding the subform on a master form, and the subform itself) two items:
Link Master Fields
Link Child Fields
Each of those properties should contain the field name of the field common to master and sub. So, for kicks n grins let's say I have in one table a field called ChassisMasterID, and in another table where I store many things about that particular chassis record I have a table called ChassisSubID. (Not that a good db designer would do this--use the same ID names everywhere.) My Link Master Fields property would then be set to ChassisMasterID, and Link Child Fields to ChassisSubID. Those fields must be included in each form's record source, and you're good to go. And they are independent of control names, so if you call your subform's control ChassisMasterID, there's still no problem.

Your table relationships are not the issue. Though they may or may not need work. I suspect that you built the form-to-sub with a wizard? Clear those two properties, put in the right field names, and get back to us.
See less See more
Okay Down,

Firstly, I posted you a beer some months ago. If you haven't received it yet, all I can surmise is that it didn't get through customs, or somehow got lost on the way to you. If the beers aren't getting through, the only alternative service I can think of providing you, is to tell everyone how great you are, and I know your modesty wouldn't allow that!

I understood some of your post (I'm slowly getting better)!
The field called Chassis Number is in both the Main Table and the Subform Table. I copied it from one to the other, so it's spelling, field size etc are exactly the same. It is a Text field, 20 characters long. A typical chassis might be something like - JA0B0513448766.

I have (had already) set the Link Master Fields and Link Child Fields to "Chassis Number", I have "enforced referential integrity and cascades". No joy, I still get the back_click error.
Possible problems:
1) For some reason the relationship between the Main and Subform tables is a "one to one". I'm sure this is wrong for starters - surely it should be a "one to many"? How do I change it?
2) When I originally created the main form, I nicked it from another database, changed the record source, removed all the fields and inserted new ones (I did this to keep some common buttons / page size / back colour to save a little time). Could it still have some residual bits and pieces from the other db? I suspect you're going to tell me that I shouldn't be nicking bits from one database and puttining them in another...
3) No, I didn't use a wizard (perhaps I should have!).

Thanks again, Down.
Gram
See less See more
Okay, forget point 1.
Because I'd copied the Chassis Number field, it had of course carried across the "No Duplicates" property.
So, I have changed to allow duplicates and voila, one to many.

Gram
Fixing the Chassis Number field property has partially fixed the problem.
If I open up the database and enter a record, it is correctly pulling the Chassis into the subform and allowing me to add parts & faults.
However, it hasn't fully worked. If I go into the database window (say, to add a new vehicle model) and then return to the main form, the back_click error appears again. Even if I don't make any changes - I just go into the db window and come back out to the main form - the error still occurs.
This won't be a problem for the person who is doing the data entry because they won't be editing the db's 'workings', but when I need to create queries and reports it's going to fail.

Is there a reason for this tempramental behaviour?
I have a similar problem with another database that calculates a total on the data entry form, based on 3 field entries. This works fine, unless I go inside the db window and then go back to the main form without shutting the db down. Instead of calculating it gives me a #Name? error where the sum should be.

Thanks,
Gram
See less See more
Any ideas?

Ideally I need to get this sorted within the next coupla days.

Thanks guys.
Gram
But then an idea came across. What if you recalculate or refresh the form (requery and recalculate) in the OnGotFocus event of the form. I have seen times when I had a form open, made a change to the table which made the recordset out of sync and the form showed the #Name.

Like I said, this was pulled out of thin air, so it may be out there...
Dealing with the most urgent db first, I tried your suggestion to requery the subform using the OnGotFocus event, and also on a custom button, and unfortunately neither worked.

I'll give this a try on the calculation in the other db, but I don't think it's going to solve my subform problem.

Gram
Okay, I've (sort of) solved the problem.

I had a button in the 'header' section of the form, that would save and close the form and then maximise the database window.
It turns out that if I just kill the form (using the Close button 'X'), instead of using the "database window button" to do it, I don't get the error when I return to the form.
Why this should be the case, I have no idea. Why would using a macro to close the form instead of the close button have any influence?

The other buttons in the top 'header' area don't seem to cause the Back_Click error, even though the form remains open. These buttons simply open the open my single-field tables (that are used for combo boxes) in datasheet view to allow new additions to the lists of vehicles faults etc).

So thanks for your help guys. I finally got there (sort of) and my boss is happy once more!

Gram
No I haven't.
Apparently it's just more tempramental than that.
I edited a macro and then went back to the form and it was fine.
Then I went to the main table and deleted the dummy records. When I went back to the form, same old error strolls into town.
It makes no difference if I minimise the form rather than closing it, and it only makes an occasional difference if I close the form with the Close button rather than a button I've created with an On-Click event.

Help?
Gram
Hi Gram,

Sorry, been away (again). Could you zip a representative sample of that mdb and send it to me at [email protected]? I do all my form-to-subform stuff with code, so I'm having a hard time getting a good idea of what you're looking at to see where the problem is. You can dummy it up with two or three fake records if it's confidential.

If I can look at it (assuming it gets through e-customs ;)) I can probably get back to you pretty quickly...
Cheers Down!
The file is pretty small zipped, so I'll post it off to you now.

Much appreciated.

Gram
Boy, ol' 123, you really had me going there for awhile. Try as I might, I couldn't get yer darn error to show up. I did ev-ry-thang, and no error nowhere. I looked at all your various events from the Properties window in form design, checked the macros, etc.......

Well. Gram. Shame on you. Not for copying the form from one db to another, because any old person can (and should, when the forms are well built) do that. But because you still have old, irrelevant, unused (that's the worst adjective I can think of) code attached to the form, which you're not using, but which contains a mighty mistake.

Do this. Open the master form (Data Entry--no comment on that form name (ahem.)). Click the 'code' button (the funky triangle with red, green, and blue points, fyi). You will then see this, because I'm just copying it here:
Code:
Option Compare Database
Option Explicit

Private Sub Back_Click()
On Error GoTo Err_Back_Click


    DoCmd.Close

Exit_Back_Click:
    Exit Sub

Err_Back_Click:
    MsgBox Err.Description
    Resume Exit_Back_Click
    
End Sub
Private Sub Back_Click()
On Error GoTo Err_Back_Click


    DoCmd.Close

Exit_Back_Click:
    Exit Sub

Err_Back_Click:
    MsgBox Err.Description
    Resume Exit_Back_Click
    
End Sub
etc. etc. What you should see, if you don't already, is this: you have two procedures (as introduced by the word "sub", short for subroutine, means a procedure, normally tied to an event or called by another subroutine; might also be a "function", but hey, that's another story) with exactly the same name. So, that error message was not lying (man, you had me looking in the MSKB...)--you have, in fact, an ambiguous procedure name, because you have two subroutines, both called "Back_Click". What's more, it's just exactly the same thing, twice; you would only need one, if you were even using code! Which you're not.

So, you need to get rid of one copy of the procedure. Delete at least this much
Code:
Private Sub Back_Click()
On Error GoTo Err_Back_Click


    DoCmd.Close

Exit_Back_Click:
    Exit Sub

Err_Back_Click:
    MsgBox Err.Description
    Resume Exit_Back_Click
    
End Sub
from the code page.

Alternatively, since you are apparently using nothing but macros, go to the Properties dialog for the form (you can close the code window), find the "has module" property, and switch it to "no". It will then prompt you saying hey are you sure you want to blow all this code away, and you may as well, because it doesn't even seem to correspond to any of your existing buttons and controls.

And then, you'll never see that error again. Oh, and do that in the other db, too, if you're not using code there. Or, at least get rid of the duplicate procedure.

No, but seriously: teaches me once again to look for the answer where MS says the answer will be. You just didn't understand the message--but I did, and I was still diggin' around...

Nuff said. Good one, though. Good one. ;)
See less See more
When I started my job, there was an IT person on site, responsible for the programming of all the site's databases, as well as spreadsheets etc.
For some reason (that I still don't comprehend), I was assigned to sit with her on her last two days of employment at the company.
She left a database unfinished, and although I had never used Access before, I was expected to at least attempt to complete it. After struggling through help files and Access books for a while I finally got it somewhere near usable, but hadn't a clue how she had programmed many of the nuances of the db.
So, when I was asked to create a new db, I nicked virtually all of the one I'd worked a little on, still nowhere near understanding what I was doing.
2 years on, and I have been promoted to the IT person, and have set up about 20 databases, gradually learning more and more, but still nicking bits from previous datbases.

Scarily, the problem that you have solved for me here stems from that original database - I'd imported the form from db to db repeatedly, altering buttons, text boxes etc as necessary, but rarely ever creating a brand new form from scratch!
So, not only did your soluiton apply to this current db, but also to the calculation problem on the other one I mentioned, and of course potentially another 15 or so databases!
After reading your post, I had to make trips to 8 different PCs in 3 offices and in several cases found useless modules behind various forms (or useless components thereon).

So once again, I've learned something rather important, rather late in the day.
As always, Down, your help is greatly appreciated.
I'll try and send you one of those new "e-beers" to your e-mail address. I think as long as you have the appropriate dispenser (I think it fits into any empty PCI slot), a frothy pint will pour pleasingly from your PC...

Cheers again.
Gram
See less See more
1 - 16 of 16 Posts
Status
Not open for further replies.
Top