asked on Problem with total in footer of form - #Error
I’ve had problems with subtotals in forms in the past but always have been able to resolve them by going over syntax with a fine-toothed comb and finding an error on my part. In this case I have done that for hours and cannot figure out what I am doing wrong. Here is the scenario:
Access 2013 linking to MS SqlServer database view.
Field is ‘CalculatedValue’, placed in a text box ‘PrintTime’ . The field displays the correct values one each row.
!['CalculatedValue' displaying on each row]()
In a text box on the form footer, I use the control source =sum([CalculatedValue]) and get #Error![#Error &*$^@!]()
.
I can replace that control source with =[CalculatedValue] and get the value of whichever row is active. But as soon as I edit the controlsource to =Sum([CalculatedValue]), the #Error returns.
![total box displays 'Calculated Value' correctly...]()
What am I doing wrong?
(NB: I upgraded to 2013 today just to see if it would resolve this issue or at least have better error description to help...)
Access 2013 linking to MS SqlServer database view.
Field is ‘CalculatedValue’, placed in a text box ‘PrintTime’ . The field displays the correct values one each row.
In a text box on the form footer, I use the control source =sum([CalculatedValue]) and get #Error
.I can replace that control source with =[CalculatedValue] and get the value of whichever row is active. But as soon as I edit the controlsource to =Sum([CalculatedValue]), the #Error returns.
What am I doing wrong?
(NB: I upgraded to 2013 today just to see if it would resolve this issue or at least have better error description to help...)
Microsoft Access
Last Comment
mbizup
ASKER
I realize that the name of this column (CalculatedValue) is confusing, but it is NOT a calculated field. That is just the name of the column, it refers to the fact that the underlying data is calculated before being written to the table.
I didn't design this database...
Thanks anyway.
I didn't design this database...
Thanks anyway.
Check the field data; do any rows return something other then a numeric?
Jim.
Jim.
ASKER
No,I don't think so - data type is number:
![snip of 'design window' of linke Sqlserver view]()
I can run this query in Access and it returns the correct number:
SELECT sum(calculatedvalue) as totaltime from dbo_vCyrTransHdrdetParts
the linked table is actually a view in Sqlserver - that would not have any effect would it?
I can run this query in Access and it returns the correct number:
SELECT sum(calculatedvalue) as totaltime from dbo_vCyrTransHdrdetParts
the linked table is actually a view in Sqlserver - that would not have any effect would it?
ASKER
Actually, to be more specific, the record source for this form is an Access query which is base on the Sqlserver query + one calculated column... not the column in question however.
Just in case any of that matters...
Just in case any of that matters...
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Good idea, I had just decided to do essentially the same thing myself - started from scratch on the form and it worked just fine. This was a redesign and I reformatted an existing form - apparently a bad idea which undoubtedly cost me far more time than it ever saved...
Thanks for the suggestion!
Thanks for the suggestion!
Hmm... the test that you ran was directly on your sql table, but you mentioned your form being bound to an Access query.
Try running that same test (your sum query) against the Access query that your form is bound to
Try running that same test (your sum query) against the Access query that your form is bound to
Ah. Missed your last post. Glad its resolved...
Try summing the expression that defines the calculated field instead.