Full Version: LinkMasterFields
UtterAccess Forums > Microsoft® Access > Access Forms
azizrasul
I have an error meaasge that comes up which says 'The LinkMasterFields property setting has produced this error: The object doesn't contain the Automation object tblDistProductApproval'. Can anyone help? I've attached the db.
imply go to the Product Development tab and try creating a record in the subform.
mike60smart
Hi Aziz
After looking at the Form I realised that you have major problems to sort.
Every one of your Tables has a PrimaryKey set as Text?
You have no auomation of the link between the MainForm and the SubForm hense the error message
Regards
Mike
BenPurser
First of all, "What Mike said..."
Y of all, "What Mike said..."
Your tables should have as their PK's SINGLE fields, which should be autonumber type. If you need to ensure in any table that X number of fields when taken together are unique, then you can index the three of them setting Unique to yes, but DON'T have compound PK's that are text fields.
That is definitely the cause as far as I can tell of your issue here.
I would also recommend that you build a query with all fields selected (instead of using the asterisk) as the record source for your forms--there's a dim bell going off in my memory that says using the asterisk can be troublesome in some circumstances.
HTH
Ben
azizrasul
Thanks guys. I've had a valuable lesson on how to choose PK's and how to create multiple field indexation. Changed the design view of my tables and re-linked the main and subforms. It now works like a charm.
uestion for guys, why do people use composite PK's? Is their a particular issue in which this is appropriate?
BenPurser
Hoo, boy, you know how to ask the loaded question...I think the only topic that's spawned more debate here at UA than this is the issue of when it's allowable to store the results of a calculation.
ours is a branch topic of another discussion...articifical (ie, autonumbers that have no other meanings) PK's vs natural (ie, a piece of data you're already using) PK's.
There are strong feelings on both sides of the fence on this. However, I think it's true to say that the majority opinion favors artificial, autonum PK's, because they aren't subject to user error, the VP of Silliness cant decide one day to change the format, which then causes headaches for the DBA's, etc. I am of this opinion--I want my PK's to be totally immune to either human error or human foolishness.
Where the multi-field PK issue complicates things even more is in part illustrated (I think) by your situation...your ability to link a form to a subform was messed up due to a compound key (BTW, it's possible that if all three fields from the PK had been in the subform's recordset, it might have worked, but let's not go back there.)
Generally, I think there's more agreement that compound PK's are problematic, and should be avoided. I usually assume that if a compound PK was thought about, you probably have a situation where you need to create a new table to hold a subset of the info in question.
HTH
Ben
azizrasul
Thanks Ben.
This is a "lo-fi" version of UA. To view the full version with more information, formatting and images, please click here.