How to increment a text box containing the value of a field by 1 with a button press

[sandwicheguy]

To 'fess up, I am still a newbie at this OOP stuff. I can do the queries and forms and such, but the controls and stuff, not to mention the VBA... Ouch. It looks like your code would work, just substitute my field and table for yours. One little problem, I don't know where to put it, I am sorry to say, but I am working on it. The Alt-F10 brings up a module I think, and into that I am supposed to paste the code beginning with 'sub' or 'Function' then the other one I paste somewhere in the event on click field... I tried various combos and keep getting errors. Exactly where do I paste these little code snippets? Nothing is ever simple the first time, thank you for your forebearance.

[June7]

All Parson's suggested code can be behind the form. In fact, the function code could even be part of the button event code. Separate function code is only useful if you want to call it from more than one form. Then the function would have to be in a general module.

The alternative is to not even bother saving a line item number and just calculate it on report when needed.

[sandwicheguy]

The alternative is to not even bother saving a line item number and just calculate it on report when needed.

Brother, I would like to do that. But in a month of working on this, I have yet to figure out how this could be done. Basically, as I have stated, the DB will have to be updated daily, in this case by a cute but ditsy brunette, via a form. I don't want her amending say 17 payments to 16 left by overtyping. The only way to show that a payment has been made is by a field [NoPay] in the table !Loans. Doing a query or report to reflect this without ammending something in the DB to reflect a payment is beyond my imagination and research in many forums. The best I could come up with is a button press on a form to ammend the payments data. If you have a better way I am all ears, and to stay on the body part analogy, all you will see in a**holes and elbows as I rush to implement it. ((:->)=

[June7]

Depending on any user to remember to click button is inherently risky. If this user has no reason to see or use these line numbers, then don't bother with them during data entry or at least don't make their generation dependent on the user. The real trick is figuring out what event to put code in so it is transparent to the user. One possibility is the form Close event but I really need to know more about structure.

The alternative is to use the RunningSum property of textbox on report to generate this line number dynamically 'on-the-fly'. The number sequence would have a life only on the report.

[orange]

Brother, I would like to do that. But in a month of working on this, I have yet to figure out how this could be done. Basically, as I have stated, the DB will have to be updated daily, in this case by a cute but ditsy brunette, via a form. I don't want her amending say 17 payments to 16 left by overtyping. The only way to show that a payment has been made is by a field [NoPay] in the table !Loans. Doing a query or report to reflect this without ammending something in the DB to reflect a payment is beyond my imagination and research in many forums. The best I could come up with is a button press on a form to ammend the payments data. If you have a better way I am all ears, and to stay on the body part analogy, all you will see in a**holes and elbows as I rush to implement it. ((:->)=

This comment may be way out of context, but I feel I should make it. It is not directed at sandwicheguy specifically. It's just that the way his comment was worded sent up a flag to me, and I've seen many of these in the last few months.

Many people, [just scan these threads to see], have acquired Access and some hardware and expect (or are expected by management) to "create" a database that is critical to the company. With no training in database design, data management, development or Access, they expect that after a few days effort, an all encompassing database application will just "materialize".

When you decide or even consider building a database, one of the first steps is to overview the business to see exactly where this proposed database will fit within "the big picture". To identify early on the scope of the activity and at the top level what info will come out, which determines what data and processes must "go in". Early in the planning will be concern on the tables and relationships; then the processes; and then the testing to assure What is needed can be done, and confirmation that How the what is being done makes sense and flows.

Many times the processes are mocked up in a demo prototype, and reviewed by the potential users to confirm "logical flow". We used to do "stub processing" where messages, and not data values, were output and the users could review, critique and suggest revisions to the flow. It isn't the norm to work for a month implementing some key function which may well have benefited from user involvement and prototyping/planning.

I'm sure that when sandwicheguy does get the kinks out and the system becomes operational, many readers would like to see any comments he may have along the lines of "lessons learned in my database project". You'd be surprised how many things are learned, not documented, and repeated.

Good luck.


As June7 has pointed out, the less the user/operator has to type, the less typos, and better data. You'll rarely get critisized for making things "too easy" or "too straightforward".

[sandwicheguy]

That was an absolutely dead-on post about many people who post. I can't put myself in at category as I have used dBase ll for a large non-profit, and the first edition of Access for keeping track of voters for a US Senate campaign. But for all practical purposes, I am a newbie as this OOP stuff brought me to my knees. But I think I finally got it sorted out by the penumbra of the emanations of the thoughts of the professionals here <g>.
First, I knew what I had to do in designing the DB and what I expected to get out of it. And I knew what had to be input. I had, however, forgotten to keep the big picture in mind and got bogged down in details. Then several people alluded to different ways to do things but I could not grasp it. Finally one guy mentioned a table for payments and it all fell into place.I just had to keep backing up from the small to the large. I had the tables wrong and all from there was a dead end. Now I can use a form to input a payment and do the rest with queries and reports.
Thanks to all for the help offered. If there is a lesson learned by me, it is don't be afraid to revisit the basics, in this case a table I left out that caused no end of trail and error.
And because I did not frame the question properly, from what I desired but instead how to do something, a lot of the help kept me going down a dead end. Finally I was able to deduce what the guru's were hinting at, I did not need a button to increment a field. In other words, do the DB right from the start.
So thanks for pointing out this endemic problem. In this case, I learned a lot just by osmosis and I really appreciate the smart guys taking time to reply to a kind of frivolous question. And I wish I was able to more quickly take a hint instead of thinking that a reply did not answer my question.
And thank you Orange for pointing out why this happens, and to all who responded. Maybe I can contribute so some other poor lost soul in the future.

[sandwicheguy]

Now how do I mark this as solved, I can't fine the thread tools mentioned.

[June7]

Thread Tools dropdown above the first post at top of thread.

[sandwicheguy]

Not there. Using Chrome on Samsung Galaxy, maybe that is why, will try fm desktop later.