I have an Access front end sitting on an MSSQL backend. I've a order
form that has been working great for a couple of years now (did the
conversion from access backend two years ago). Just recently however,
line items will display but will not add to the total on the invoice.
We've seen this happen with various scenarios, many different order
types, different stores, different everything.

At first I thought it to be a corruption issue, so we've since moved to
having a clean build of the MDE and copying the fresh copy to the local
machines each time someone logs in.

Additionally, the invoice can be reprinted immediately and it will work
fine. We've not been able to recreate this issue on demand, and the
people running it aren't saavy enough to give me any more details than
to show me the invoice that didn't print.

Any thoughts?

1. Not saved.
Have you explicitly save the record before printing? If it is not yet saved,
the unsaved record the user sees on screen will not match the saved record
printed in the report. (This might also explain why it works when they try
again: by then the record has actually been saved.)

2. Data types
Invoices often have calculated fields, and JET 4 is not good at guessing the
types. This can lead to inconsistent results. More info:
Calculated fields misinterpreted
at:
http://allenbrowne.com/ser-45.html

Likewise, be sure to set the Format property of the controls on the report -
both the controls bound to calculated query fields, and those that contain a
calculation such as =Sum([Amount])

If is it not a calculated field that gives the problem, what is the data
type of the problem field(s)?

--
Allen Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I have an Access front end sitting on an MSSQL backend. I've a order
> form that has been working great for a couple of years now (did the
> conversion from access backend two years ago). Just recently however,
> line items will display but will not add to the total on the invoice.
> We've seen this happen with various scenarios, many different order
> types, different stores, different everything.
>
> At first I thought it to be a corruption issue, so we've since moved to
> having a clean build of the MDE and copying the fresh copy to the local
> machines each time someone logs in.
>
> Additionally, the invoice can be reprinted immediately and it will work
> fine. We've not been able to recreate this issue on demand, and the
> people running it aren't saavy enough to give me any more details than
> to show me the invoice that didn't print.
>
> Any thoughts?

Thanks for taking a minute to respond.

1) The records are saved each time they leave the subform or try to add
a new record. I had thought this initially might be the problem, but
that was when the only examples we had seen were only losing the last
line. We've now seen examples of losing two or three.

2) The calculations are all done in Access and saved to the SQL record
(price each x QTY + tax + freight + unpaid balance - amount paid, etc).
Typically the money fields are stored as money in SQL and the qty
fields as int.

As mentioned, this has worked fine for a couple of years already.

Thanks.

Allen Browne wrote:
> 1. Not saved.
> Have you explicitly save the record before printing? If it is not yet saved,
> the unsaved record the user sees on screen will not match the saved record
> printed in the report. (This might also explain why it works when they try
> again: by then the record has actually been saved.)
>
> 2. Data types
> Invoices often have calculated fields, and JET 4 is not good at guessing the
> types. This can lead to inconsistent results. More info:
> Calculated fields misinterpreted
> at:
> http://allenbrowne.com/ser-45.html
>
> Likewise, be sure to set the Format property of the controls on the report -
> both the controls bound to calculated query fields, and those that contain a
> calculation such as =Sum([Amount])
>
> If is it not a calculated field that gives the problem, what is the data
> type of the problem field(s)?
>
> --
> Allen Browne - Microsoft MVP. Perth, Western Australia.
> Tips for Access users - http://allenbrowne.com/tips.html
> Reply to group, rather than allenbrowne at mvps dot org.
>
> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> >I have an Access front end sitting on an MSSQL backend. I've a order
> > form that has been working great for a couple of years now (did the
> > conversion from access backend two years ago). Just recently however,
> > line items will display but will not add to the total on the invoice.
> > We've seen this happen with various scenarios, many different order
> > types, different stores, different everything.
> >
> > At first I thought it to be a corruption issue, so we've since moved to
> > having a clean build of the MDE and copying the fresh copy to the local
> > machines each time someone logs in.
> >
> > Additionally, the invoice can be reprinted immediately and it will work
> > fine. We've not been able to recreate this issue on demand, and the
> > people running it aren't saavy enough to give me any more details than
> > to show me the invoice that didn't print.
> >
> > Any thoughts?