Copy Value Into Form (1 Viewer)

MS Access 2003
We would like to be able to click on K_01 or the other K Numbers and copy the text into the Memo field.

Ideally, If possible for only K_01,
Could we enter the = 1,038 (number of shares) and the number 0.346 (Dividend Value) into two separate fields and have their contents copied into the memo field as
#1,030 Shares @ $0.346?

Thank you for your assistance,
Nicole

In the click event of K_01 you would have
Me.Memofield= "#" & Me.Number of Shares & " Shares @ " & Me.DividendValue

However I am struggling to see any benefit of doing this, and the general consensus is never to store data that can be calculated?

Thank you for your suggest.
Can you please advise us as to what will have done wrong
I have renamed K01 to K01_cmdCopy
===
Private Sub K01_cmdCopy_Click()
Me.Memofield= "#" & Me.Number of Shares & " Shares @ " & Me.DividendValue
End Sub
===
Our Volunteer Directors wants to the information that is going into the Memo Field
Thank you,
Nicole

Nicole, like Gasman i fail to follow what you end games is? I have added Gasman's formula to your database and it works as intended, however the questions i ask is why a memo field a text field can except 225 characters and will you have a different record for daily changes? Please supply more details if you require further assistance

Ypma

I did not download your DB.
You need to replace my control names with yours.
If any control names have spaces like [Number of Shares] then enclose them in square brackets as I have done so here.

If he has to see it as a sentence, I'd be inclined to use a form with
NumberOfShares Control then a label with the centre text and then the DividendValue control and bring them as close together as you can.

HTH

access2010 said:

Thank you for your suggest.
Can you please advise us as to what will have done wrong
I have renamed K01 to K01_cmdCopy
===
Private Sub K01_cmdCopy_Click()
Me.Memofield= "#" & Me.Number of Shares & " Shares @ " & Me.DividendValue
End Sub
===
Our Volunteer Directors wants to the information that is going into the Memo Field
Thank you,
Nicole

Click to expand...

THANK YOU

The project that you have helped us on works and will save us lots of data entry time.

I appreciated everyone's help.

Nicole

If the director needs to see that, then it could just as easy be an unbound control and put the value there. No need to store. Put the code in the current event of the form as well?.
You might need to use the NZ() function if any could be Null.

HTH

Thank you for your suggestion.

We are not programmers in this volunteer office and since your Data Base system W O R K S we will not change the program.

I DO appreciate your assistance and suggestion

Regards
Nicole

access2010 said:

We are not programmers in this volunteer office and since your Data Base system W O R K S we will not change the program.

Click to expand...

I have done 3 or possibly 4 databases for charities.

In all cases, I set about changing the flat file structure provided to the correct multi table structure.

I now think this may have been a mistake!

People are used to Excel (flat file), and they understand it.

The changes I made, sort of lock the database, making it inaccessible to a competent excel user.

This might not be a good direction for a Charity to take.

Sent from my SM-G925F using Tapatalk

Tony,
Even in Excel I would have put in a cell =A1 & A2 & A3 to concatenate the data for viewing. In fact I do that for someone in the office now who then just copies and pastes that column into an email.

Surely the same approach?

Hi Gasman, (Sorry, I don't have a record of your real name) I was making a general observation about charities using MS Access databases. If a charity was to use an MS Access database, then how they manage the data structures within it might be an important consideration. An MS Access programmer's Instinct would be to advise them to use the multi table structure and not use a flat file structure. However once you move away from the flat file structure, making changes to your database will requires someone with a reasonably good knowledge of how MS Access works. From the point of view of a charity, it may not be possible for them to pay for the services of a professional programmer. Hence the choice of a flat file structure might well be a sensible option.

Hi Tony,

It's Paul. I agree, and that is why I suggested the unbound control as a director wanted to see a sentence in one place and would not care as to how it was done?. I am actually in that predicament with a charity I volunteer for. As long as they get what is requested, they are not concerned as to how I go about it.
Fortunately for me, I have learnt a lot since joining this forum, so it makes my life a little easier when asked for such and such.

This is certainly a fine line to walk. On the one hand, storing calculated values can actually be dangerous and cause real fiscal damage if actions are taken based on invalid information. With a spreadsheet, the calculations can be expected to always be current but not so in a database because there are multiple ways to update a record and if you don't properly perform the calculation every time the record is updated, then the calculated data might not actually reflect the underlying parts.

Is this more dangerous than a spreadsheet where the calculation on row 40 might be different from the calculation on row 20?

I prefer calculating values in queries because I believe that is the lesser danger. Or, if you are using A2007 or newer, you have the option of creating a calculated column. This is limited functionality but will work OK provided all the arguments come from the same row. But since you can't ALWAYS do the calculations this way, it can be confusing to the user and rather than have them learn two methods, I think it is better to teach them one method.

The best thing you can do is to build in some instructional material. Create forms and reports that explain certain technical aspects of the app and how to use them for other purposes or how to copy them and change them. Having a beginner help you with this will go a long way towards targeting the explanation to the level of a beginner. But there is still no getting around the problem that whomever will take this database over will need a certain clarity of thought to grasp the technical details. A database created by a beginner would be full of patches and work arounds and just plain bad choices but a database made by a professional should provide a clean framework that new features can be added to without disrupting the whole app.

When I create databases that I know will be owned by non-professionals, I frequently make conscious decisions to dumb down certain functions to make them easier to understand. Slick is a dirty word when you are developing for non-professionals. Simple is always better.

Thanks for all the interesting comments.

We had an Ms-Access data base built for us M A N Y YEARS ago which works with periodic adjustments, which we prefer to use instead of Excel.

Nicole