essaytee
Need a good one-liner.
- Local time
- Today, 12:56
- Joined
- Oct 20, 2008
- Messages
- 512
Okay, first up, I know how to resolve the following but what a pain in the .......
In one of my applications I keep track of the user logins (session_id, version, dates, times, username, machine name) along with which backend data files (full paths) they are opening/closing.
The session information is recorded in another central backend data file. Users never get to see this other than a Session_ID number on the main form. The session data file is only opened as needed and closed immediately, no linked tables. It's purely for my purposes only; stats. Session data dates back to 2002, so there's a heap information there.
I have two tables;
tbl_Session
I've written a separate application (solely for me) where I can view the session data. In the first instance I can check which users are still logged in and to which backend data files. It will also show users that have subsequently logged out as those particular date/time fields will not be empty.
I have routines in place whereby I transfer the completed (logged out sessions) to the table, tbl_Sessions_Histroy, and then delete those entries from the table, tbl_Session. So tbl_Session will always have minimal entries.
Over the years I've done some Compact and Repair and now realise that there must have been at least one entry in the tbl_Session table. Two days ago, I did a Compact and Repair (hadn't done one for, well ages) but this time there mustn't have been an entry in the tbl_Session table. This effectively reset the Session_ID number back to 1. I didn't realise this immediately, not until I was transferring records to the history table, all of a sudden I got duplicate error issues.
What a pain.
I am a proponent of the AutoNumber but under this scenario it could bite you in the ....... if you're not careful.
Steve.
In one of my applications I keep track of the user logins (session_id, version, dates, times, username, machine name) along with which backend data files (full paths) they are opening/closing.
The session information is recorded in another central backend data file. Users never get to see this other than a Session_ID number on the main form. The session data file is only opened as needed and closed immediately, no linked tables. It's purely for my purposes only; stats. Session data dates back to 2002, so there's a heap information there.
I have two tables;
tbl_Session
Session_ID - Autonumber
Other session fields
tbl_Session_HistoryOther session fields
Same as tbl_Session though Session_ID is not an Autonumber.
The process is that my application directly updates the tbl_Session table with relevant session data. Session_ID is automatically created.
I've written a separate application (solely for me) where I can view the session data. In the first instance I can check which users are still logged in and to which backend data files. It will also show users that have subsequently logged out as those particular date/time fields will not be empty.
I have routines in place whereby I transfer the completed (logged out sessions) to the table, tbl_Sessions_Histroy, and then delete those entries from the table, tbl_Session. So tbl_Session will always have minimal entries.
Over the years I've done some Compact and Repair and now realise that there must have been at least one entry in the tbl_Session table. Two days ago, I did a Compact and Repair (hadn't done one for, well ages) but this time there mustn't have been an entry in the tbl_Session table. This effectively reset the Session_ID number back to 1. I didn't realise this immediately, not until I was transferring records to the history table, all of a sudden I got duplicate error issues.
What a pain.
I am a proponent of the AutoNumber but under this scenario it could bite you in the ....... if you're not careful.
Steve.