By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
460,029 Members | 1,274 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 460,029 IT Pros & Developers. It's quick & easy.

1 + 1 sometimes = 7.8

P: n/a
I inherited the following Access XP app:

There are about a dozen data files, most are linked.
The goal is to add, subtract, multiply and divide some numbers to
produce a number.
The resultset is exported to Excel for review.

Data file sizes vary from 50meg to 1.2gig.

Total size of all MDBs is alittle under 3gig ( not used all at the same
time, max size used at any one time is <500meg )

The number of records the tables range from 5,000 to 1.6 million.

It's a datamart, no data changes unless I change it and no one else has
access to the data files.

I have done the Repair / compact / decompile / import into new, and even
copied the modules to notepad, created a new mdb and then created new
modules and then copy and pasted back from notepad.

There are DoEvents and .Idle in the code to make sure read locks are not
a problem.

Running the process with a master file of about 500k records, it can be
seen that the earlier records are processed alittle faster than the later
records.

Each function ends with:
On Error resume next
If not MySet is null then 'similar code for each recordset
MySet.close
setMySet = Nothing
Endif
DbEngine.idle
DoEvents
exit function

Problem: Each batch ( via a macro ) execution of the same code produces
different numbers, some are correct, some are not.
When I step through the code ( sets <= 2000 records ), all
numbers are always correct.
Does anyone have experience with different results from the same data and
same code?
Thank you for your help,

John Bickmore
Nov 13 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
xzzy wrote:
I inherited the following Access XP app:

There are about a dozen data files, most are linked.
The goal is to add, subtract, multiply and divide some numbers to
produce a number.
The resultset is exported to Excel for review.

There are DoEvents and .Idle in the code to make sure read locks are not
a problem.

Running the process with a master file of about 500k records, it can be
seen that the earlier records are processed alittle faster than the later
records.

Each function ends with:
On Error resume next


I'd throw in some error handling to see if there are any errors raised.

What's the data look like before it goes to Excel?

Any chance of testing with a subset of the data?

--
'-------------------------------
' John Mishefske
'-------------------------------

Nov 13 '05 #2

P: n/a
every routine has error checking code, there are no errors

running with a subset of the data still has the same problems

John Bickmore

"John Mishefske" <mi****@execpc.com> wrote in message
news:10*************@corp.supernews.com...
xzzy wrote:
I inherited the following Access XP app:

There are about a dozen data files, most are linked.
The goal is to add, subtract, multiply and divide some numbers to
produce a number.
The resultset is exported to Excel for review.

There are DoEvents and .Idle in the code to make sure read locks are not a problem.

Running the process with a master file of about 500k records, it can be seen that the earlier records are processed alittle faster than the later records.

Each function ends with:
On Error resume next


I'd throw in some error handling to see if there are any errors raised.

What's the data look like before it goes to Excel?

Any chance of testing with a subset of the data?

--
'-------------------------------
' John Mishefske
'-------------------------------

Nov 13 '05 #3

P: n/a
When you divide you will get decimal numbers. Further manipulation of
the data will result in a propogations of errors from rounding. So if
you are adding/dividing/adding/dividing... several fields you may be
propagating rounding errors. Real hassel if this is the case.

Rich

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 13 '05 #4

P: n/a

A better example is:

1st execution: 10 + 20 = 35

2nd Execution: 10 + 20 = 27

etc . . .

Manually stepping thru the code: 10 + 20 = 30 every time
John Bickmore
"Rich P" <rp*****@aol.com> wrote in message
news:41**********************@news.newsgroups.ws.. .
When you divide you will get decimal numbers. Further manipulation of
the data will result in a propogations of errors from rounding. So if
you are adding/dividing/adding/dividing... several fields you may be
propagating rounding errors. Real hassel if this is the case.

Rich

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!

Nov 13 '05 #5

P: n/a
for debugging, if you are doing lots of additions and dividing, I would
create a temp table with 3 fields which will capture each value val1 +
val2 = answerval

I am just guessing that your app is performing many calculations (too
many to manually go through in the debugger). So for each calculation
you will use dao to write val1 to field1, val2 to field2 and answerval
to field3

Set rsTmp to CurrentDB.OpenRecordset("tblTmp")
...
val3 = val1 + val2
rsTmp.AddNew
rsTmp!field1 = val1
rsTmp!field2 = val2
rsTmp!field3 = val3
rsTmp.Update
...
val4 = val3/something else
rsTmp.AddNew
rsTmp!field1 = val3
rsTmp!field2 = something else
rsTmp!field3 = val4
...

Then you can look to see at what point the calculations start becoming
incorrect. This may seem cumbersom, but debugging is always cumbersom.
If a lot of the calculations are repetitive, you could probably use a
loop(s) (if you want to go crazy, you could probably use recursion if
you are drilling down through some values till you get to the value that
can't be broken any further - loops way easier).

HTH
Rich

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 13 '05 #6

P: n/a
Had one more thought on the debugging. You could add two more fields to
your temp table, a rowcount field (so you know where the failure begins)
and a field where you specify the respective operation (add, subtract,
mult,div)

Then when the original procedure is completed and the temp table is full
of data you can loop through the temp table as follows

Row = i
Select Case Operation
case "add"
x = field1 + field2
case "sub"
x = field1 - field2
...
if x <> fld3 then problem here! where fld3 contains the value from the
actual calculation. if x = fld3 then continue to next row.
Rich

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 13 '05 #7

P: n/a
On Fri, 23 Jul 2004 20:06:02 GMT, "xzzy" <mr********@comcast.net> wrote:

If code gives correct answer sometimes and wrong answers sometimes, I suspect
something isn't getting cleared between program steps. A computer is a pretty
bumb machine. It will do whatever you tell it to do. And it will do it the
same every time - usually.

If you run the same data twice, do you get the same wrong answers in the same
places? If yes, most likely a program error. If no, could be a hardware error
(memory, internal or external to cpu). If you do a cold boot between runs do
you get the same results? If you make run 2 on a different machine, are the
results the same as for original machine? Are any other programs running in
the background?

Manually steping thru gives correct answers all the time, Sounds like the code
is faster than the machine. ie. insufficient time between calculations for all
the little electrons to come to rest. Put some null statements in the code to
cause a delay between the various steps. If this gives correct answers, it is
beginning to look like a hardware, or temperature of hardware, problem.

All bets are off when running big number crunching programs if the cpu has been
over clocked.

Chuck
---

A better example is:

1st execution: 10 + 20 = 35

2nd Execution: 10 + 20 = 27

etc . . .

Manually stepping thru the code: 10 + 20 = 30 every time
John Bickmore
"Rich P" <rp*****@aol.com> wrote in message
news:41**********************@news.newsgroups.ws. ..
When you divide you will get decimal numbers. Further manipulation of
the data will result in a propogations of errors from rounding. So if
you are adding/dividing/adding/dividing... several fields you may be
propagating rounding errors. Real hassel if this is the case.

Rich

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!


Nov 13 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.