Store field value in a table field Access 2010 - ms-access

I have a problem I have a simple calculation carried out on a form
=[subtotal]-[discount]+[delivery]
I then want to store the result in my order table under the field TotalPrice
I have hunted around google but can not find anything that helps me.
I know its not good to store field values in tables but it needs to be done.
Thanks in advance.
Just to be clear.
[subtotal] [discount] and [delivery] are all text boxes on a form. there is then a box called [Total] what appears in the textbox called [total] is what I want to then store the field in my order table.

It would be better to create a query, and then have whomever/whatever needs that calculated value use the query instead of the table directly.
HOWEVER, you could create a trigger on the form on something like the OnCurrent event, and then have that trigger execute the following.
me.txtCalcField = me.subtotal - me.discount + me.delivery
However, that would fire any time you changed records. It might be slightly better to check if it's set first
if isnull me.txtCalcField then
me.txtCalcField = me.subtotal - me.discount + me.delivery
endif
But then if its components values get reset, your value doesn't get updated. In which case, you could put triggers on those fields as well (AfterUpdate events perhaps).
OR
You could check the value's aren't different each time.
if isnull me.txtCalcField then
if me.txtCalcField <> me.subtotal - me.discount + me.delivery then
me.txtCalcField = me.subtotal - me.discount + me.delivery
endif
endif
(which probably won't work properly with Reals, but might with Currency)
Of course, that's all assuming the only way the components of txtCalcField will be updated is through the form - forever.
It's all a dog's breakfast - in which case, I direct you back to my first statement - use a query.

Related

Sum Values not equal to a space from a Control Source in MS Access

As the subject expresses, I'm trying to sum the values of a string field where spaces may exist. It must be done this way, unfortunately.
The database is very old. The original developer chose to make all fields Text fields; to get over the null value problems, a function was written in VB6 to replace any null value with a space. This cannot be changed.
Fast forward to now, I'm trying to create a report that sums the length field without changing spaces to nulls first, and it should be done entirely through the control source property of the report.
I've added some of what I've tried below, but every time the report is run, I receive:
Data Type Mismatch
...and I'm not sure how to get around it.
Ideally, I'd like to keep the users out of the database completely, and just add a combo box that lists the reports created in the database so they can be opened by name without having to run any additional update queries first.
=Sum(IIf([MY_LEN]<>" ",DCount("[MY_LEN]","MY_TABLE"),0))
=Sum(Nz(Iif(Trim([MY_LEN])='',Null,[MY_LEN]),0))
=DSum("[MY_LEN]","[MY_TABLE]","[MY_LEN]<>' '")
=Sum(Iif(Val([MY_LEN])>0,[MY_LEN],0))
=(SELECT Sum([MY_LEN]) AS MyLen FROM MY_TABLE WHERE (((MY_TABLE.[MY_LEN])<>' ')))
Is this possible?
Can't compare anything to Null. Can't say If x = Null Then because Null is undefined. So you can't test if undefined = undefined. Use If IsNull(x) Then in VBA and Is Null in query criteria. Don't really need IIf() for Sum() aggregate, other aggregates such as Count or Avg would.
To handle possible space, empty string, or Null for a text field holding numeric data.
=Sum(Val([MY_LEN] & ""))

What ID does a ComboBox reference?

I am attempting to maintain and fix a horribly out-of-date CRM designed by an ex-employee ~4-5 years ago in Access 2007. I have brought it into Access 2013 and fixed a ton of stuff up, but I am still running into many problems.
I spent a good 4 hours today attempting to figure out why certain values didn't line up. These values were being pulled from a SELECT statement on a Combo Box over a stored Query which simply returns a table with a few extra rows. Great.
However this value (a number) doesn't appear to correlate with what we expect. I enter in one value, save the ticket, and a completely different value gets stored into the table. Opening up the ticket, I see the value that I expect. Digging deeper, I found the following difference:
Set value_1 = Me.RegistrationID // What's being stored in the table
Set value_2 = Me.RegistrationID.Column(0) // What we expect
Surprise surprise! This is a Combo Box and some value is being stored in the table. The Control Source is "RegistrationID" and the Row Source is the query in question.
However I do not know what it is! This specific value correlating to the Combo Box appears to pull the correct data when we later open the tickets. However I have a strong feeling that this could be why many tickets from before one of the rows was deleted all appear to have invalid RegistrationID's.
How badly can this break?
How easily can we correct tens of thousands of tickets?
How can I fix this to store the correct value?
This is what I expect is happening.
Your combo box row source is based on a Select query which returns and displays multiple rows. For example:
Select RegistrationID, CustomerID, CustomerName From MyTable;
The Control Source for the combo box is bound to RegistrationID which is part of the Forms Record Source.
The issue is the bound column. If we set the bound column in our example to 1, then we get the behavior your are describing with:
Set value_1 = Me.RegistrationID - Set's value to CustomerID (may appear correct)
Set value_2 = Me.RegistrationID.Column(0) - position 0 from our query (RegistrationID)
Further building on our query example, you can say:
Me.TextBox1 = Me.RegistrationID.Column(0) - RegistrationID
Me.TextBox2 = Me.RegistrationID.Column(1) - CustomerID
Me.TextBox3 = Me.RegistrationID.Column(2) - CustomerName
The RegistrationID is what normally should be stored in the table.
As long as your form shows any values that directly relate to this RegistrationID you're fine.
I would start by checking to see under the format setting to see if column widths are set properly and I would also check under the data section to see if the bound column is correct. I might also throw in an after update macro/vba sub routine that saves the record. Hope this helps.

How do I change the values of a radio button from 1, 2, 3, etc to text values?

I have created a small database in Access 2007 that consists of one table and two forms, one for entering data, and one for retrieving data.
My problem is this: On my input form I have a group box with three radio buttons in it. The question being asked is Is the element a sensor?
The buttons represent Yes, No, and Don’t Know.
In the database I have a column named Sensor to hold the value the user chose, but since the radio buttons return a value of 1 for yes, 2 for no, or 3 for don't know, it makes generating a report or query that makes sense to the user very difficult.
At this point I’m writing huge SQL statements with nested iif’s to return the data the way I want to see it.
Is there a way to populate the table with data the way I want to see it (yes, no, don’t know) instead of populating it with 1’s 2’s or 3’s? This is a bound form by the way, I wish I would have done it unbound, but I can’t go back now.
I would suggest not using the radio buttons, and instead opt for a combo box. You'll be able to use string values for the results directly in the combo box.
Now if you are dead set on using radio buttons, try this:
Add a new field to your table that holds text. Bind this to a hidden text box on your form.
Then, add a BeforeUpdate event (or AfterUpdate depending on what you are doing) to the radio group. Add code similar to the following:
Sub RadioGroup_BeforeUpdate(cancel As Integer)
Select Case Me.RadioGroup.Value
case 1
Me.hiddenTextField.value = "Yes"
case 2
Me.hiddenTextField.value = "No"
case else
Me.hiddenTextField.value = "Don't Know"
End Select
End Sub
Now when you save the record, the human readable value will be available in the new field you added.
"since the radio buttons return a value of 1 for yes, 2 for no, or 3 for don't know, it makes generating a report or query that makes sense to the user very difficult."
Store those 3 pairs as rows in a Sensor_Values table:
sval descriptor
1 yes
2 no
3 don't know
Then you can join that table to the table which includes the stored Sensor numbers.
SELECT yt.Sensor, sv.descriptor
FROM
YourTable AS yt
INNER JOIN Sensor_Values AS sv
ON yt.Sensor = sv.sval;
If you're opposed to creating and joining a lookup table, you could use a Switch() expression in your queries to translate the numeric Sensor values to their text forms.
SELECT
Switch(
Sensor = 1, "yes",
Sensor = 2, "no",
Sensor = 3, "don't know"
) AS sensor_text
FROM YourTable;
The Switch() approach can work, but can be more challenging to maintain compared to the lookup table approach.
My intention here was to show you fairly simple methods to use the option group value as a number instead of "populate the table with data the way I want to see it (yes, no, don’t know) instead of populating it with 1’s 2’s or 3’s"
As a general rule, you will be better off working with Access controls as they were designed to be used. Break that rule whenever you have a compelling reason ... but breaking the rule then requires additional efforts from you ... like more VBA code. The approaches I suggested don't require any VBA.
you could use a Select Case when creating the select string, instead of having iif's nested in the SQL.
Select Case Me.rdoSensor
Case 1
sSQL=sSQL & " AND Sensor='Yes'"
Case 2
sSQL=sSQL & " AND Sensor='No'"
Case 3
sSQL=sSQL & " AND Sensor='Don''t know'"
End Select

Efficient use of calculations in MS Access

This is the kind of thing I feel I should already know, but don't...
In MS Access, if a query consists of n calculated fields (say calc_1, calc_2, .... calc_n) but I only want to use a subset of them in a particular form or report - say calc_x, calc_y and calc_z - would Access calculate all n calculations when running SELECT calc_x, calc_y, calc_z FROM myquery and then return the ones I want, or would it be smart enough to only calculate calc_x, calc_y and calc_z?
In my case I'm using Access 2003 but presumably the answer is the same for all versions.
Access is smart and don't calculate not-visible fields.
Tried with Access 2003
Like #David, I did not believe #Andreas's answer at first. So I tested it myself as follows. I created the following function:
Function Watch(Val, Optional CalledFrom As String = "")
Debug.Print Val, CalledFrom
Watch = Val
End Function
Then I created a table named "Dummy" with a single field named "ID". I created a form and used the following as the form's RecordSource:
SELECT Watch([ID],"ShowInForm") AS ShowInForm,
Watch([ID],"HideFromForm") AS HideFromForm
FROM Dummy;
I added a single textbox control with a ControlSource of ShowInForm.
I then opened the form and got this in the immediate window:
1 ShowInForm
1 ShowInForm
1 ShowInForm
I then went back to the RecordSource and previewed it in Datasheet view and got this:
1 ShowInForm
1 HideFromForm
I'm not sure why the "ShowInForm" expression is evaluated three times in the form, but it seems pretty clear that the unused field, "HideFromForm", does not get evaluated.
To address #HansUp's comment, I went back and saved a query named "Qry":
SELECT Watch([ID],"ShowInForm") AS ShowInForm,
Watch([ID],"HideFromForm") AS HideFromForm
FROM Dummy;
Then changed the form RecordSource to:
Select ShowInForm FROM Qry
This produced the same result as before when I opened the form (ie, 3 lines of 1 ShowInForm). Interestingly, when I opened the RecordSource in datasheet view I got this:
1 ShowInForm
1 ShowInForm
In other words, it evaluated the ShowInForm field twice. Presumably, once in "Qry" and again in the RecordSource query.
The end result is still a confirmation of #Andreas's answer.
If you include the calculated fields in the SELECT clause of your report or form's recordsource, it will calculate them for each row AS IT IS RETRIEVED.
If you leave them out of the SELECT and include the calculations only in the ControlSource properties of controls on your report/form, then what you say is true.
Also, if you do any sorting/grouping on the calculations or put criteria on them, all rows will be calculated.
Thus, in this recordsource:
SELECT Field1/Field2 As Ratio1, Field3/Field4 As Ratio2, FIeld1, Field2, Field3, Field4
FROM MyTable;
...for each row that is retrieved, both calculations will be executed regardless of whether or not the result is used in the form or report.
If you want to delay calculations to the last possible moment, do NOT include them in the SQL recordsource, but just use them as the ControlSources of the controls that are displaying the calculations. However, this has the downside that you'll see the calculations painting onscreen in many cases.
EDIT:
It seems this may not be correct, but I feel there's something going on here that is not completely explained by #mwolfe02's answer. I'll just leave this here for further discussion.
I put calculations like this on the server side.. computed columns are awesome.
I think that Access finally got this feature in 2007, I don't know how people ever survived without it.

Ms access: Autocomplete field with values from another table

please forgive me for my poor english and my big ignorance on programming.
I'm using Ms Access 2003.
Let's suppose i have two tables:
Table1: ID (autonumber), [...], Keywords (memo)
Table2: ID (autonumber), Keyword (text)
I want:
1) As the user types letters in Table1.Keywords that my database searches in Table2.keyword for the nearest value and proposes it by autocompleting (just like google proposes a search word as you type)
2) When user presses ", " that he can add one more keyword in the same field (and the autocomplete still runs for this next value)
3) If he types a keyword not included in Table2 and press ", " that he is asked if he wants this value to be added in Table2
Well, i'm not sure if all these are clear... maybe they are a lot of things...
But i'd appreciate if you could help me...
Thanks in advance
J.
It would be complicated to do it with a single control, but with two controls, a dropdown list for choosing the value to add, and a textbox displaying the memo field, you could have the combo box's AfterUpdate event append a comma and the chosen value to the existing data. Something like this:
Private Sub cmbChooseKeyword_AfterUpdate()
If Not IsNull(me!cmbChooseKeyword) Then
Me!txtKeywordMemo = (Me!txtKeywordMemo + ", ") & Me!cmbChooseKeyword
End If
End Sub
You'd also want the rowsource of your combo box to not list items that are already entered, so this is one way that would work for a relatively short list of keywords:
SELECT tblKeywords.*
FROM tblKeywords
WHERE InStr(Forms!MyForm!txtKeywordMemo, tblKeywords.Keyword) = 0;
Then you'd add:
Me.Dirty = False
Me!cmbChooseKeyword.Requery
...at the end of the AfterUpdate code above (inside the End If):
Private Sub cmbChooseKeyword_AfterUpdate()
If Not IsNull(me!cmbChooseKeyword) Then
Me!txtKeywordMemo = (Me!txtKeywordMemo + ", ") & Me!cmbChooseKeyword
Me.Dirty = False
Me!cmbChooseKeyword.Requery
End If
End Sub
...and you'd want to add the requery to the OnCurrent event of your form, as well (so that when you arrive on a record, the combo box already omits any keywords that are already in the list).
Now, all that said, I'd completely recommend against doing this. This is a denormalized way to store the data, and this leads to problems:
what if you want to delete one keyword?
what if you want the keywords to be sorted in alphabeticsal order?
what if you have 100s of thousands of records and you want to search this field with LIKE "*Keyword*" -- will it bog down to be terribly slow (no indexes, and not used well even if there were)?
You really should use a proper many-to-many structure, with an additional table between the one where you're currently storing the keyword memo and your keyword list table. This "joins" the two, and would then give you a list.
You could then use a subform with a dropdown list to populate each row of the join table.
If you like presenting the keywords on reports as a comma-separated list (as you're currently storing them), you can write a simple function to do the concatenation for you at the presentation layer of your reports (concatenation functions for that purpose are a frequent Access question here on Stackoverflow).
Why not use a "Combo Box" and set its Row Source Type to Table/Query, and then make the Row Source a query on the second table. Just make sure you don't turn on Limit to List.
CodeSlave mentions a way that will work. But it will only work for one value. There is no way to do the multi-words-separated-by-commas thing. Only one word at a time.
As for the Adding new values. The combobox control support an OnNotInList event which can do what you say.
Seth