It's not that bad ... other than the active screen and all this Active stuff, which of course is totally unreliable, but see my last post - I actually created a test database and utilized it. I think the answer to this whole thread lies in my last post, believe it or not.
I was also somewhat confused until I remembered it was inserting line breaks - adjusting the row height of the table in datasheet mode, I then realized it actually was putting all the changes in.
Another style pointer... why did you choose to make this a function? There are only two times when you need to make something a function. First, when you intended to return a value - but you don't return a value here. Second, if you intended to run this in MACRO context, because a MACRO requires a function for its RunCode entry-point name. Any other time, what you wrote might as well be a SUB.
BTW 'functionally' it doesn't make any difference if a sub is written as a function.
A third reason for doing just that is so it can be run directly from the immediate window
Indeed some developers only ever write code as functions.
However its not a policy I subscribe to
It's not that bad ... other than the active screen and all this Active stuff, which of course is totally unreliable, but see my last post - I actually created a test database and utilized it. I think the answer to this whole thread lies in my last post, believe it or not.
I was also somewhat confused until I remembered it was inserting line breaks - adjusting the row height of the table in datasheet mode, I then realized it actually was putting all the changes in.
For an audit example using data macros see this. It is not dependent on forms and form events. It will handle changes made via table, query, form or vba.