Ben
A couple observations...
Your SNS table has multiple fields named [xxxxxDate], so I'm guessing you
are tracking when (i.e., the date) things happen in relation to (?) a
project. Again, as I mentioned in my earlier email, using multiple columns
to track multiple (types of) dates is how you'd do it with a spreadsheet.
To get more use from Access, consider creating another "many" table that
holds four fields (at a minimum):
trelProjectEvents
ProjectEventID (PK)
ProjectID (FK - ?SNSID)
DateType (FK - create a lookkup table with the types of events you
track - e.g., planning, deployment, ....)
ProjectEventDate
This way, you only have as many rows as you have dates for, and you can add
new events to track by just adding them to the lookup table.
Take a look at your multiple [xxxxxStatus] fields ... the same holds as for
the [xxxxxDate] fields.
I don't understand why/how your "project" table is related to your WAR
table.
I don't understand what is being stored in your [Leads] field ... from the
name of it, it sounds like it could have "many" things in it.
So, you're saying you want to have multiple rows in your SNSAI table that
duplicate each other ("copy ..."). Why? If you are using a standard main
form/subform construction, the subform (SNSAI) data will automatically be
given the correct parent ID. And I'm guessing you aren't actually giving
the same [Owner] the same [ActionItem], so how does copying help? You've
described "how" ... now, "why", as in "how does having the copy help
you/your users?"
Regards
Jeff Boyce
Microsoft Office/Access MVP