IMHO
Every record in every table should have a unique primary key.
This is what the autonumber/guid field is for, refer to the normalization link in my prior post.
So in your case, IMHO, you should have something like the following going on in your database:
(in the following, [PK] is an autonumber field typecast long
[FK_*] is a Field typecast Numeric(long) with a one to many relationship set to the [employeetable]![PK] enforced no cascades
[employeetable]
[employeetable]![PK]
[employeetable]!{....other related fields, Family name, First name, etc.
[employeetimetable]
[employeetimetable]![PK]
[employeetimetable]![FK_EmployeeTable]
[employeetimetable]!{date and time, other related fields}
So example
[employeetable]
[PK][some related fields....]
[1][familyname1][firstname1][MI1][BadgeNumber1]
(.... many records ....)
[255][familyname255][firstname255][MI255][BadgeNumber255]
[employeetimetable]
[pk][fk_employeetable][some related fields]
[1][1][2013-07-16 13:00][2013-07-16 23:00]
[2][16][2013-07-17 13:00][2013-07-17 23:00]
[3][255][2013-07-18 13:00][2013-07-18 23:00]
[4][255][2013-07-19 13:00][2013-07-19 23:00]
[5][16][2013-06-15 13:00][2015-07-17 23:00]
(.... many records ....)
[1200][1][2014-07-16 13:00][2014-07-16 23:00]
[1201][16][2014-07-17 13:00][2014-07-17 23:00]
[1203][255][2014-07-18 13:00][2014-07-18 23:00]
[1204][255][2014-07-19 13:00][2014-07-19 23:00]
[1305][16][2014-06-15 13:00][2014-07-17 23:00]
(.... many records ....)
[6151][1][2015-07-16 13:00][2019-07-16 23:00]
[7562][16][2016-07-17 13:00][2019-07-17 23:00]
[9515][255][2017-07-18 13:00][2019-07-18 23:00]
[9616][255][2013-07-19 13:00][2019-07-19 23:00]
[9999][16][2018-06-15 13:00][2019-07-17 23:00]
Now if I clicked on your button, and the current record is
[employeetimetable]!
[7562][16][2013-07-17 13:00][2013-07-17 23:00]
Then the value I'd pass in the code would be:
[employeetimetable]![PK]=7562
Or lookat [employeetimetable]![PK]=9616 ... note how you can find that record without any other information! You know exactly that [employeetable]![PK]=16 is the employee (which now with query you can pull that employee's name from the [employeetable], and you can also filter the [employeetimetable] for that employee, feed those records to the edit form
and
now your form knows exactly which record(s) to filter down to in the recordset, the user can only edit the record(s) (using the concept earlier) and all is good in the Emerald City...
Normalization usually keeps the Flying Monkeys from shredding your mind!
>>> as for not exporting the PK field or FK... build your query and do not include it in the visible fields...
- SELECT [field1], [field2]
-
FROM [table1]
-
WHERE ([Field3] = 16);
Of course the "16" could be a variable/parameter based value. You would export this query as normal and only the records where Field3=16 would be exported and Field3 would not show up in the exported data.