Chris_C_NZ
New member
- Local time
- Today, 07:36
- Joined
- Oct 8, 2015
- Messages
- 3
Hi everyone,
Post #2, so go easy. I'm also not a native MS Access developer..so terminology may not be correct...anyways..
I've developed an application in Access 2010 that enables a team of colleagues to record information, much like a survey, and am looking to hand this over to the team for operational management.
The database is split, with the backend 'hidden' in a shared network folder.
The front end contains effectively 3 data input forms, 1 search form. The data input forms connect to the same table in the back end, and the responses are mutually exclusive (I.e. Q1 in form 1 is held in its own field to Q1 of form 2). The PK of this table is called record_ID and is set to be an autonumber. There is no ability to delete records - only add new or amend existing.
Each user can input without issue, and using the in-built nav buttons, can find records. However...
...it is likely that this table is going to grow rapidly and have a few thousand records to choose from. This mandated the need for users to search and find the appropriate record_id number to use in the form nav button area. Great. Easy. Right? Wrong.
On a daily basis, the PK autonumber may skip (I.e add 2 not 1). This means that on the search function (which executes a select query from the table to display the record_id and is then used by the user in the nav area) goes out of sync with the form.
I googled, and found there could be bugs between jet connectivity and compact and repair, so I disabled the compact/repair function.
Next day, it happened again, so I locked the databases down with passwords. It happened again that day.
So now I'm scratching my head. I know that using a PK as the record number isn't the smartest thing to do, but without creating my own set of navigation buttons (and why should I when Access kindly provides them?) am going to continue getting this issue. Its almost like the autonumber does its thing, and the form actively checks to see how many records are in the table, hence causing the sync issue.
Is there any way to change how the nav buttons do their thing (i.e. the x of y records can be preset to select * from table where record_id = n) ?
I cant be alone in this situation, and scratching my head to know how to move forward. Any ideas?
Post #2, so go easy. I'm also not a native MS Access developer..so terminology may not be correct...anyways..
I've developed an application in Access 2010 that enables a team of colleagues to record information, much like a survey, and am looking to hand this over to the team for operational management.
The database is split, with the backend 'hidden' in a shared network folder.
The front end contains effectively 3 data input forms, 1 search form. The data input forms connect to the same table in the back end, and the responses are mutually exclusive (I.e. Q1 in form 1 is held in its own field to Q1 of form 2). The PK of this table is called record_ID and is set to be an autonumber. There is no ability to delete records - only add new or amend existing.
Each user can input without issue, and using the in-built nav buttons, can find records. However...
...it is likely that this table is going to grow rapidly and have a few thousand records to choose from. This mandated the need for users to search and find the appropriate record_id number to use in the form nav button area. Great. Easy. Right? Wrong.
On a daily basis, the PK autonumber may skip (I.e add 2 not 1). This means that on the search function (which executes a select query from the table to display the record_id and is then used by the user in the nav area) goes out of sync with the form.
I googled, and found there could be bugs between jet connectivity and compact and repair, so I disabled the compact/repair function.
Next day, it happened again, so I locked the databases down with passwords. It happened again that day.
So now I'm scratching my head. I know that using a PK as the record number isn't the smartest thing to do, but without creating my own set of navigation buttons (and why should I when Access kindly provides them?) am going to continue getting this issue. Its almost like the autonumber does its thing, and the form actively checks to see how many records are in the table, hence causing the sync issue.
Is there any way to change how the nav buttons do their thing (i.e. the x of y records can be preset to select * from table where record_id = n) ?
I cant be alone in this situation, and scratching my head to know how to move forward. Any ideas?
