Query results inconsistent between computers

G

Guest

I have a situation where a few users are experiencing either a lockup or
“Report Cancelled†when trying to run routine reports that have worked for
them in the past. At first it appeared that perhaps there was a problem with
printer drivers since the symptoms were the same as a diagnosed problem with
that as a cause. The situation is this: I promoted a new level of MyApp.mde
(level 6.07) in February. A few users reported having these problems, so I
had them send me their MyApp_be.mdb tables; I could not reproduce the problem
on my machines with either Access 2002 or 2003. I sent them stand-alone
copies of 6.07 in zipped format. They still experience the problem.

So the deal is with the same data and same level of MyApp.mde, we get
different results. I have been unsuccessful in helping them install
MyApp.mdb on their machines (ActiveX problems I don’t know how to fix). I
have imbedded trace lines in the code and had them run it while on the phone
with me. The trace gets us to the point that one of the application fails to
run a query used to post summary data to a table that reflects the monthly
totals by Asset/Fund/Year/Month, from which I extract the Asset and Fund
Balances for a pseudo-Balance Sheet report which includes January 1 opening
balance, Current Month Opening Balance, Receipts, Disbursements, and Current
Month Closing Balance.

In order to get the users back on their feet, I have sent them the Year-end
2006 level of the program 5.30, re-numbered to 6.01 for internal reasons;
they can get the reports using that level.

I attempted to walk two of the users through the displaying of the Database
form, and had them run the queries; one gave up in frustration. With the
other user, we got to the point where a first query qGiftFundAssetTotalsAll
summarizes all donations (income) at the Year/date level by Income Account
and calculates the GiftMonth for later use. This runs properly for them.

The second query, qIncomeByAstFundMoAll uses the qGiftFundAssetTotalsAll
query to sum all Income accounts together by Fund/Asset/Year/Month for
subsequent posting to the tBalanceSheet table. This is where the process
bombs out, with an error message stating that
qGiftFundAssetTotalsAll.GiftDate produced an error (I don’t have the exact
message; the user is in Hawaii, and I was lucky to have her on the phone for
the hour that it took to get to that point.

I have looked at the last modified date in the query listing in the Database
form, and none of the queries used in this procedure has been changed
recently: the first has a Modified date of 3/2/03 and the second has 4/7/05.

The changes in the intervening releases do not have anything to do with the
queries that are failing.

I have queried the users who are having problems, and the first one to
respond has the same level of MS Jet Engine (4.0.8618.0) that I do….


Question: Is there something that can account for different query results
on different machines, given the same program and data?

I’d appreciate any help!
 
A

Allen Browne

Wow, Gordon. It probably isn't helping much to say these things can be hell
to debug. You already know that! :)

The exact error message from the user in Hawai would probably be the best
clue. Perhaps they could email a screenshot of the error to you next time it
occurs (i.e. Alt+PrintScrn, and paste into an email.)

I wasn't clear about the ActiveX problem: if there is any bad reference on
the user's machine, it could affect any query that calls a VBA function such
as Nz(), Left(), or one of your own functions.

Any chance it could be a JET sandbox issue?
http://office.microsoft.com/assista...3&CTT=8&Origin=EC011081751033&Product=acc2003

Could any of these users have different regional settings that could affect
the interpretation of dates or other types?
http://allenbrowne.com/ser-45.html

There's a whole raft of different bugs that could cause a bug to show only
when particular combinations of data arise:
http://allenbrowne.com/tips.html#Bug Engine
However, if you have the same version of Access, the same version of JET,
the same settings, and the same data, you would see those same bugs on your
machine as well.

Hopefully somethere there is of use, or perhaps someone else has another
suggestion.
 
G

Guest

Allen, first my thanks for the time you spent thinking about this issue. I
really appreciate it, and got a bit of an education tracing all your
references. Particularly helpful was the seeing how to add references to
existing tables.

I think I am getting closer to finding the problem. I think the ActiveX
issue has to do with a DateTimePicker I had inserted on a form at a point
where a new user was unable to use the "Calendar" form I use for all date
control. The DTP works o.k. in my .mde version, but apparently in .mdb mode,
the users don't have all the code I have in Office Development library. I
have removed the DTP (that user got his problem solved with MS help) since it
is no longer needed. I'm trying to line up a test this afternoon with the
..mdb verson again.

I think from your writeup that the JET sandbox is available on 2003+. My
program is 2002, so I don't see that as an issue. Also, I don't use any of
the examples of exploitable instructions (KILL, etc.).

Regional settings don't apply. We just work with dates such as CurrentDate,
CurrentMonth, CurrentYear, all of which are DateTime format. Nothing is real
time, and programatically I check that all dates entered are within the
CurrentYear, etc.

I also am trying to get one of the users to test modifications to the
queries that are involved. I noticed that a couple of them have
"Expressions" that apparently were generated by the Wizard(?) since I have
absolutely no recollection of putting them in the queries, and removing them
doesn't seem to hurt anything. One of the error messages appears to have
referred to one of these expressions, again not used.

I was able to get one of my users to run the "new" code this morning, and it
worked for her; however she did not have all the problems that have been
reported, so I am reluctant to declare victory and go home.

Thanks again!!
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top