Bilbo_Baggins_Esq
Registered User.
- Local time
- Yesterday, 20:18
- Joined
- Jul 5, 2007
- Messages
- 586
Hi All,
Log time no see!
I hope all are well since I last visited.
I've been super busy as a v- on Microsoft's Frontier Team since 2007, but unfortunately since our "end of the road" team is Consumer support based, my contact with Access is minimal (limited to countries wherein there is no "Pro Support" available). And even in those circumstances I am forbade from working with code.
What brings me here today is an Access database I am building for my contract manager to run a random monthly bonus drawing for two groups of employees. Based on performance in three categories, employees could have up to 3 entries, per week, per month in the random drawing.
The problem I'm having, I have not previously experienced in .mdb format and since I am using Access 2007 and or Access 2010 in .accdb format, I am tempted to attribute this very annoying attribute to a bug, and frankly am tempted to repro it and write a @#^ bug, but thought I'd check in here first.
Basically, there is are main tables for:
1. Groups
2. Employees
3. Weeks
4. Employee log
all have primary indexes and are fully related to each other properly.
I have the data tables in one db (data db) and keep the db with the forms and associated code separate with links to the tables in the first db (forms db).
I am using ADO to communicate with the data db from the forms db.
My aim is to be able to compile the code db and keep it blocked but still allow them access to their data.
I've set a personal goal to build this seemingly simple database without any built in Access queries (just forms with code and tables with data).
So far things have been fine on this goal and three days ago, had built everything necessary to start building the process to run the actual random drawing.
I open one last form in which the user is to view the weeks for the chosen month for the purpose of making sure there are the expected number of updated employee records. If the user does not like the count of records, he/she can cancel back to the front form and double check the employee records for those months. If the user does like them, can click a button to start the actual drawing process.
My first incarnation of this final form was to base it off a query which brought the necessary records together (since there is no need to do any actual editing).
The problem is, there are records shown which do not even exist in the main table from which the query is built!?!?!
Oddly enough, while troubleshooting this phenomenon, I discovered if I manually close the form and reopen it, the spurious record is no longer there!!!
So I tried to code an extra close and open of the form, but that did not solve the problem.
I also discovered that if I put a 15-20 second delay between the extra close and open, that would prevent the spurious record from appearing.
Getting very annoyed by this phenomenon, today I built a temp table and all the code necessary to physically place all the necessary records in the temp table and based this last form off the physical table.
I thought sure it would stop the spurious record from appearing, and it did!
But, form some SUPER annoying reason, the count of employee records field(which comes from the same @%#^ table as the rest of the data) takes about a minute to two minutes to actually update on the screen!!!!
WHAT THE BLEEP IS THAT ABOUT!!!
Again, if I manually close the form and reopen it, the field is visible but also again, hard coding a close/reopen does not work around the problem unless I hard code about a 10-15 second delay.
I need some insights here...
Have I built something wrong?
Should I use a different method to get data and run action queries?
(My experience is somewhat limited in this regard)
Is there a more effective way of working around what (to me) appears to be a bug?
If necessary, I’d be happy attach copies of the two different incarnations of these databases, but I guess perhaps one of you gurus may have previously encountered this or similar scenarios have some “general” tips which may help.
Many thanks in advance.
Log time no see!
I hope all are well since I last visited.
I've been super busy as a v- on Microsoft's Frontier Team since 2007, but unfortunately since our "end of the road" team is Consumer support based, my contact with Access is minimal (limited to countries wherein there is no "Pro Support" available). And even in those circumstances I am forbade from working with code.
What brings me here today is an Access database I am building for my contract manager to run a random monthly bonus drawing for two groups of employees. Based on performance in three categories, employees could have up to 3 entries, per week, per month in the random drawing.
The problem I'm having, I have not previously experienced in .mdb format and since I am using Access 2007 and or Access 2010 in .accdb format, I am tempted to attribute this very annoying attribute to a bug, and frankly am tempted to repro it and write a @#^ bug, but thought I'd check in here first.
Basically, there is are main tables for:
1. Groups
2. Employees
3. Weeks
4. Employee log
all have primary indexes and are fully related to each other properly.
I have the data tables in one db (data db) and keep the db with the forms and associated code separate with links to the tables in the first db (forms db).
I am using ADO to communicate with the data db from the forms db.
My aim is to be able to compile the code db and keep it blocked but still allow them access to their data.
I've set a personal goal to build this seemingly simple database without any built in Access queries (just forms with code and tables with data).
So far things have been fine on this goal and three days ago, had built everything necessary to start building the process to run the actual random drawing.
I open one last form in which the user is to view the weeks for the chosen month for the purpose of making sure there are the expected number of updated employee records. If the user does not like the count of records, he/she can cancel back to the front form and double check the employee records for those months. If the user does like them, can click a button to start the actual drawing process.
My first incarnation of this final form was to base it off a query which brought the necessary records together (since there is no need to do any actual editing).
The problem is, there are records shown which do not even exist in the main table from which the query is built!?!?!
Oddly enough, while troubleshooting this phenomenon, I discovered if I manually close the form and reopen it, the spurious record is no longer there!!!
So I tried to code an extra close and open of the form, but that did not solve the problem.
I also discovered that if I put a 15-20 second delay between the extra close and open, that would prevent the spurious record from appearing.
Getting very annoyed by this phenomenon, today I built a temp table and all the code necessary to physically place all the necessary records in the temp table and based this last form off the physical table.
I thought sure it would stop the spurious record from appearing, and it did!
But, form some SUPER annoying reason, the count of employee records field(which comes from the same @%#^ table as the rest of the data) takes about a minute to two minutes to actually update on the screen!!!!
WHAT THE BLEEP IS THAT ABOUT!!!
Again, if I manually close the form and reopen it, the field is visible but also again, hard coding a close/reopen does not work around the problem unless I hard code about a 10-15 second delay.
I need some insights here...
Have I built something wrong?
Should I use a different method to get data and run action queries?
(My experience is somewhat limited in this regard)
Is there a more effective way of working around what (to me) appears to be a bug?
If necessary, I’d be happy attach copies of the two different incarnations of these databases, but I guess perhaps one of you gurus may have previously encountered this or similar scenarios have some “general” tips which may help.
Many thanks in advance.
