I'm trying to display the sum of a field in a text box in the form footer. The field is not calculated in any way.
Here are a couple of the things I've tried:
=Sum([txtWeldInches])
=Sum([WeldInches])
=Sum(CDbl([txtWeldInches]))
=Sum(CDbl([WeldInches]))
...well you get the idea. Each iteration I've used results in the Text Box displaying #Error Without exception.
I've used similar constructs in different forms in the same project, so I'm not sure what the problem might be.
Has anyone run into this before?
EDIT:
I ended up writing a VBA routine to update the boxes when it was likely that they would be changed rather than trying to get a bound sum() function to work.
http://support.microsoft.com/kb/199355
All of the domain functions are based on the same query (over the underlying recordset). If one of the bound functions on the form has a binding error, all of the functions on the form will return an error.
In other words, make sure all your footer controls are resolving properly and not hitting any nulls.
If you use a SUM or AVG then make sure you are also using the Nz function:
ControlSource = =SUM(NZ([FIELD],0))
Is the field "WeldInches" existing in the data source for this form?
What datatype the field "WeldInches" is?
EDIT: I have looked at all your comments. If it doesn't work by databinding, try and use the unbounded way. At runtime, get the value of WeldInches using DSUM and set the footer textbox's value when the form loads.
Also, remember to update it at places where you think the SUM could change.
I had the same problem as Rister.
The source of the form was an underlying query.
I had a bound text box named txtQty on this form. Its control source was Qty (based on the underlying query of the form).
I created an unbound text box and entered =SUM([txtQty]) and received an error.
I tried various ways to find a solution and was very desperate.
Then I deleted the underlying query and created a new one using the same name and fields as before.
Then I entered =SUM([Qty]) into the unbound text box on the form and voila, it worked. Note that I didn't enter the name of the bound text box (txtQty) into the expression, but its control source (Qty). I don't know why, but it worked for me.
I know you said "Form" but for those who have issues with the Sum formula in an Access "Report" the formula has to be in the Report Footer NOT the Page footer. Took me a while to figure it out as Access defaults to only showing the page footer.
You want to sum by the name of the column in the record source: SUM([WeldInches])
Make sure there are no other textboxes with the name WeldInches.
Related
This is the screenshot of how the final output should look.
However, in the screenshot you will find that purchase total (calculated text label) is the sum total of the first order description Total (calculated at form level): Final Form view section display
The above screenshot result is the output of this formula
=[OrderDescription_tbl].[Form]![Total]
If I use this formula
=Sum([OrderDescription_tbl].[Form]![Total])
The output is #Error.
Troubleshooting I did,
I had created a grand total at the footer of the Subform using
the Sum function and visible parameter set to No and wanted to
reference the output to the Main form Purchase total. How to solve this problem?
However, in the screenshot you will see the number of boxes
count (Not calculated and is a table column), I used the same Sum()
function in the order_description subform. It gives the correct
output. Why is there a difference in output for the same function
one, against the Non-calculated table column and the other, a calculated form text label?
I have used this formula too
=IIf([OrderDescription_tbl].[Form]![Total]>0,Sum([OrderDescription_tbl].[Form]![Total]),0)
Output is still #Error
I have used an query which calculates sum total of each line item and tried to reference this query as
a)=Sum([Query1]![Expr1]) received #Error
b)[Query1]![Expr1] received #Name?
As an alternative to the DSum solution proposed by Kostas, you can use the following workaround:
in the footer of the subform, insert a textBox with the =Sum([Total]) formula, name the textBox BigTotal (or whatever you want)
in the main form, refer to that control: =mySubFormControl.Form!BigTotal
make the subform's footer hidden if you want.
If you have large data sets, this should be faster than the DSum. Also if the subform has an embedded query as its recordSource, you avoid the creation of a queryDef.
Try the DSum() function:
=DSum("[Total]",[OrderDescription_tbl].[Form].[RecordSource])
Thanks! I have been able to solve it using the existing structure only. In this regard I referenced Northwind database.Although,my database would have been more specific and different from Northwind,some aspects from Northwind did give me hints on what to change. The trick was - I had several lookups fixed on numerical columns like unit_rate(and this unit_rate referred a product portfolio table containing product offering of our company).Once, I removed the lookup aspect of these column values, #Error as well as Name? error were automatically resolved. I created a grand total with Visible parameter set to No inside the order description subform and referenced the output of this form to the grand_total text label in the outer form as seen in the screenshots shared.😀 Thank you for the support#Ren Kessler and I will share this is Stackoverflow too so that others can take advice from my case scenario. Ren Kessler I will use your method in some other way,may be in this development scenario but for some other context. I found it quite interesting and I havent tried it. Apart from my reply, I would like to quote you and your solution method too.Total_Calculation_subforminternal_view_Expression_builder_for_grandtotal_textlabel
This is the solution Given by Ren Kessler(Facebook group member):" I solved it in a very convoluted way. I hope someone has a better solution than mine.
I created a series of fields on my form (not fields in a table, but just on the form) that reference the fields on the subform. Then I performed all my math using these form fields. It was the easiest way I could find.
It seems clumsy, but works. As well, it made it easy to use these fields on a report (in my case, an invoice).
In previous versions I did not have to do this. I took a 2002 app where the math worked on the sub form, and used the exact same steps in 2016 and got #error, just like you. This system solved it, but it just doesn't seem right."
This is probably a beginner question and I am missing something fundamental, but I appreciate anyone's time and effort.
I have inherited an Access database, where the data is kept in a separate file to the forms and reports.
A report is used to create a letter to summarise a set of results.
The relevant part is in the Detail section of the report, where pairs of Text Box controls are used to show the name of the test, and the result.
The behaviour of the text boxes is that they are hidden (including the name of the test) when the value is zero in the database. However, sometimes we need to include a zero value.
Is this default behaviour?
I have inspected the VBA project and cannot find any logic that is hiding the text boxes.
Other information:
The field is set up as Number (double)
The default value for the field has been made empty, not 0 which seems to be the default.
I have tried using the format property for the control using #;#;0;"" as described here (http://www.experts-exchange.com/questions/21525364/Show-zero-values-as-dashes-on-an-Access-report.html)
I have also tried using ControlSource =IIF([fieldvalue]>0,[fieldvalue],"0") which did show a zero, but the descriptor text box still disappeared, and it was appearing as 0 whether the database field value was 0 or nothing.
Please let me know of any other details that would be helpful.
Thank you everyone for your help.
I hadn't traced back for enough in the logic chain, which #KenWhite's answer gave me the hint for.
The issue was in the query underlying the report - the logic for the field had conditional parameters on it, using IIf() and NULL / 0 checks.
I am looking at the following post SO Question and am struggling with how to perform the answer to the question:
The way that I ended up solving this was to add a field to T, and have that field updated during the AfterUpdate() event with the value from the DLookup() call. Because the field is now no longer query-based, it can be used to filter the form.
Specifically, what are the steps to update the 'table field' with the value from the DLookup() call? Do I place the DLookup in VB code?
I always prefer using vb codes but that is because I don't feel as flexible in the things I want to accomplish using macros. However, if you don't want to use VB code you can create a bound text box that captures the value of the unbound DLookup. then have the bound text box set to visible = false. that way you will not have two box with the same information on your form.
I have a report in Access with 3 fields on it: Width, Height and Area.
Width and Height are pulled from the table the report is bound to, whilst Area should be calculated (height * width). I've set the Control Source of the Area to = [Height] * [Width], but on opening the form the field displays #Type!, in typically descriptive Access errors fashion, with nice use of # and ! to make it impossible to accurately Google... but I digress. I have no idea what #Type! means and Access doesn't want to tell me.
I can't understand this. In the bound table, Height and Width are Integers, and are both populated in the record being viewed (so it's not a NULL problem). If I change the Control Source to something really simple - like =[Height], it spits out #Error! instead (again, thanks for the useful intel, Access. We'd be lost without you). Even = 1 spits out #Error!.
Any idea why Access hates my control sources?
You probably have a name clash, i.e. Access is picking up the Width and Height members of the report object rather than the fields called Width and Height.
I would create a new query and simply rename the problematic fields in it. So, if you're using the query designer:
add the primary key and any other non-problematic field, then WidthValue: Width and HeightValue: Height as additional columns;
finally, set the report's record source to be the query rather than the table directly, and update the calculated control formulae accordingly.
This is a pretty simplistic calculation. Any reason why you don't create a query, do the calculation in said query, and bind the report to the query instead? No sense killing yourself trying to figure this out.
In fact, now that I'm thinking about it, Height and Width are probably reserved words, as they're properties of a control. Maybe change them to HHeight and WWidth or something?
When access created a report it uses the field name of queries to create the name of related control on the report. then if you use the query field names later it actually refers to the report control with the same name. so solution, either rename the report field name to something different from query fields or fully qualify the query field name [query].[field] to force access to use the query field name.
Microsoft does not list Height and Width as reserved words, however, they are used when sizing forms and reports.
I had a related problem where my Form would give me this error. Changing the Form property Data Entry to Yes solved this issue. Not sure that this solves your exact issue, but perhaps in the Report Properties you can find a related field?
right click on your AREA filed and select properties then go to EVENT tab then click on "ON ENTER" select from drop down list [Event Procedure] and click on the dots on the right side and go to "MICROSOFT VISUAL BASIC FOR APPLICATION" on this window type this code above the "End Sub"
Area = Height * Width
but attention the name you enter on this code must be able on your database and as the same as you things that type in the code line
good luck
I have searched everywhere for this and tried different criteria but for whatever reason the form which has a control box set to open a report which is based upon a query will not pull the data within the date range. Instead keep getting enter parameter value dialogue box.
The criteria in the query is stated as Between [Forms]![Form1].[StartDt] And [Forms]![Form1].[EndDt]
The form has two date inputs StartDt and EndDt and is pointed to open the report. Without the above criteria in the query the form opens the report and produces all the dates. So at least it allows me to enter dates and is connected to the query and report but without the criteria fails to isolate data within the required range.
When I place into the query containing the criteria (as above) under the appointment date field all im getting are two parameter value dialogue boxes one after the other displaying Forms!Form1.StartDt and the second, Forms!Form1.EndDt.
Apologies for being long winded but am desperate to solve this issue am new to access.
Thanks to everyone for any input.
Iain
It seems you have an error in your names. One of the easiest ways to check form names is to use the immediate window. Type ctrl+G and you will end up in the code window with the cursor in the Immediate window. With the form open and a date filled in, type or paste
?forms!form1!StartDt
Into the immediate window and hit return. If you get an error, it means that you have a name wrong somewhere along the line, either your form is not called Form1, and form names can be a little complicated, or your control is not called StartDt. So this is where the version of Access comes in. In Access 2010, if you type Forms! on the criteria line of a query and wait a second, it will give you a list of forms. Pick your form from the list and type ! after the name, Access will come back with a list of controls. Pick your control. You should now have the right form and control name.