some questions that may help clarify:
a) are compound PK/FK required? if design is still flexible, use of single artificial (meaningless) PK is often preferable, with UNIQUE asserted over alternate (compound key) attributes. May be cast “in stone” though …
b) a VIEW established to project the data your application requires could be useful, not only to bypass compound key complexities but in fact to “project” the data your app really wants.
My take is that if your app is asking for specific table and column data from a number of sources, it knows too much about the DB schema already.
As for some clever VB syntax miracle/workaround, I have no idea.