By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,700 Members | 1,553 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,700 IT Pros & Developers. It's quick & easy.

Using variable I/O in same Sub Procedure - rs.update

P: 28
Good Evening, "Long time listener, first time caller."

MS Access 2007 - VBA - DAO

I have a procedure that updates values from textboxes on a form to a table with a rs object update method. Within that same procedure I am looking to pass the values back out to the same form with a different recordset. Is there a danger or reason for concern given the rs.update happens within the same sub I'm pulling the table values from? Or is there a "reasonable" time-frame I should give the write event to the table?

Thanks,
P

Example:

Expand|Select|Wrap|Line Numbers
  1. button_click()
  2. rs.AddNew
  3. rs!myvalue = text1
  4. rs.update
  5.  
  6. .....more code......
  7.  
  8. db.openrecordset
  9. rs.fields("myvalue") = text1
  10.  
  11. End Sub
  12.  
Feb 14 '14 #1

✓ answered by jimatqsi

Once you do the rs.update you're good to go, there's no delay to worry about. However, if you're writing new records you should follow the rs.update with
Expand|Select|Wrap|Line Numbers
  1. rs.bookmark=rs.lastmodified
Jim

Share this Question
Share on Google+
7 Replies


Expert 100+
P: 1,240
No problem, but I'm not at all sure about the code you posted.

First, be sure to add
Expand|Select|Wrap|Line Numbers
  1. if me.dirty then me.dirty=false
before executing the code behind the form (between lines 1 and 2 above). That writes any changes on the screen to the recordset.

You haven't shown enough code for us to know for sure what is going on. Presumably rs and db have been defined and set elsewhere. But if the field is already on the screen it's not clear why you would need to pass the value back to the screen. That's where you got it to begin with.

Forget screens and recordsets for moment. Tell me if the piece of data that is being updated is in two different tables or not. If two different tables are needing to be udpated, the form on the screen can do one and your vba code can reach out to the other table and do that one. But if you're just trying to refresh the screen to get the data you just added to some table, and the form itself can not do that update, then you need only do a
Expand|Select|Wrap|Line Numbers
  1. me.requery
to pull a new copy of the recordset onto the form.

Jim
Feb 15 '14 #2

P: 28
Hi Jim,

Thanks for taking the time to help. I appreciate your time.

Let me preface with stating all of my objects are unbound. I wasn't completely clear with my explanation. My code is working fine so it's more of a question about the "predictability" of Access or Ace when and how it's writing to a table. Basically, can I pull out a value from the table I just wrote to in the same sub procedure?

1. Button Click

2. Use record-set behind an unbound button to save a "New" record to a table.

3. I then pull out the primary key value (which is autonumber), back to the form front end to a text box. (My conern is here. Will the autonumber have enough time to generate from step 2 before the code moves to this 3rd step?)

4. End Sub


I'm pulling out the primary key immediately to my form so I can then pass it to another form. Hope this makes sense.

Thanks again!
Paul
Feb 16 '14 #3

Expert 100+
P: 1,240
Once you do the rs.update you're good to go, there's no delay to worry about. However, if you're writing new records you should follow the rs.update with
Expand|Select|Wrap|Line Numbers
  1. rs.bookmark=rs.lastmodified
Jim
Feb 16 '14 #4

NeoPa
Expert Mod 15k+
P: 31,769
pwag
"Basically, can I pull out a value from the table I just wrote to in the same sub procedure?"
Simply put - Yes. As Jim says, once the .Update() has been executed the table contains the data.

There is a caveat to that, which is that this behaviour would be modified if you were using transactions in your code. In this latter case the data would be ready to access only when the transaction is completed. I suspect that isn't an issue for you though.
Feb 16 '14 #5

P: 28
Thanks Jim and NeoPa,

NeoPa,

Could you briefly explain what you mean by "transactions?" You're correct, it probably doesn't apply here though.

Paul
Feb 16 '14 #6

Expert 100+
P: 1,240
Paul, transaction processing is a way to start a posting process, for example, and un-do whatever is done if the process does not finish completely without error. You do it all or you do nothing.

Here is a good MS article on the topic.
http://msdn.microsoft.com/en-us/libr...ffice.12).aspx

Jim
Feb 16 '14 #7

NeoPa
Expert Mod 15k+
P: 31,769
That about says it Paul. Not much I can add to that.
Feb 17 '14 #8

Post your reply

Sign in to post your reply or Sign up for a free account.