Forum Discussion
First addnew record slow
I am running an Access split database application using Office 365. I have a form that is not bound to a table -- the user fills in multiple fields on the form and then clicks an "Add Record" button...
Thanks again. Yes, I saw the posting you refer to last week and attempted that. That was actually the source for me to get the syntax of how to open a password protected database.
I did try today to set up a simple split database. On the back end the database contained one table with an index autonumber field, and a simple field that holds a date. On my laptop, I created another database that links to that table across the same network, I created a form that has only 2 objects: a textbox for input, formatted as a date, and a button that triggers the code to take the user input and use the ADDNEW method to add it to the table. I did not get any unusual delays for the first or any of the subsequent records I added. Now the trick is to figure out why. I can tell you that although I have a few dozen editing checks to make sure the user is following the rules, in my testing I commented out all of that and just did the ADDNEW based on user input. Got the same issue -- an extremely poor response time for the first record, and a very fast response for subsequent record additions. I will do some tinkering with the code, but off the top of my head it's hard to understand why the identical code runs over and over and only misbehaves the first time it is run in a session.
Thanks for hearing me out -- I very much appreciate the additional sets of eyes.
I did try today to set up a simple split database. On the back end the database contained one table with an index autonumber field, and a simple field that holds a date. On my laptop, I created another database that links to that table across the same network, I created a form that has only 2 objects: a textbox for input, formatted as a date, and a button that triggers the code to take the user input and use the ADDNEW method to add it to the table. I did not get any unusual delays for the first or any of the subsequent records I added. Now the trick is to figure out why. I can tell you that although I have a few dozen editing checks to make sure the user is following the rules, in my testing I commented out all of that and just did the ADDNEW based on user input. Got the same issue -- an extremely poor response time for the first record, and a very fast response for subsequent record additions. I will do some tinkering with the code, but off the top of my head it's hard to understand why the identical code runs over and over and only misbehaves the first time it is run in a session.
Thanks for hearing me out -- I very much appreciate the additional sets of eyes.
out of curiosity, why are you using .Addnew method of a Recordset.
why not use a Bound Form?
why not use a Bound Form?
well there are people Disagreeing on Mr.NolongerSet and he himself admit prefers Bound form (his last comment).
of course it is up to your choice. but looks like you are getting an obstacle already.you can limit the number of records being edited/created by returning 1 record (for editing) and no record for adding:
for editing:
select * from yourTable where (CriteriaHere);
for new record:
select * from yourTable where (1=0);
- There are lots of posts about this, and folks tend to get pretty defensive about their preferred approach to forms,
https://nolongerset.com/use-unbound-forms-to-add-records/
https://www.access-programmers.co.uk/forums/threads/unbound-vs-bound-forms.322411/
Much of what you can do with an unbound form you can do with one that's bound. But I'm sure I can build much more user-friendly interfaces with better error handling with unbound forms. I feel I have far greater control, and if the GUI is designed well for your users, there's less training involved.
That said, there's definitely more work to reap the advantages. However, I've been doing it long enough so that it's not really a big deal to me at this point.