A2K on 2003 Server

[Guest]

For the super techies...

We just upgraded our NT server to 2003. After the upgrade, we moved an A2K
database that updates records in a back end to the server and set it up in
Scheduler to run with a command parameter. The backend resides on the same
physical computer and drive as the .mdb. The program had been working fine
on a WinXP Pro workstation (also using a command parameter) with local copies
of the backend databases.

Since installing on the new server, about every 4th or 5th time the
application tries to run, it throws the following error:

Application failure msaccess.exe 10.0.2627.1 at offset 0x0000a8f3

When you view the details, you see the following:

Exception information:
Code: 0x00000b20
Flags: 0x00000000
Record: 0x00000000c0000005
Address: 0x00000000

On most occasions, but not all, this results in a lock file for the front end.

To try to find out what was going on, we put extensive error trapping and
logging into the front end .mdb. Nothing shows up, not even in the Form_Open
of the form that is automatically opened when the app starts. We've run the
program on the XP Pro development machine at least one hundred times trying
to get it to fail. Nada, nothing. It works perfectly.

The problem appears to be compatibility issues with 2003 Server. Has anyone
heard of anything like this going on?

Any input/help deeply appreciated.

Thanks,
Bruce

 

[Allen Browne]

Not sure why the particular combination is causing it to fault, but you
desperately need to apply some service packs to your Office 2002.

You may also need service packs for JET:
http://support.microsoft.com/kb/239114

Once you have both those sorted out, open the front end (holding down Shift
to bypass any opening form/code/macro), and choose:
Tools | Database Utilities | Compact/Repair
The front end caches info relating to the attached tables. That info will be
wrong after your upgrade. Compacting the front end causes Access to drop
that cached info, and can prevent crashes.

 

[Guest]

Thanks, Allen. I'll copy our SA on your comments and post back here with the
results.

Bruce

 

[Guest]

Allen,
One more note: The front end does a compact & repair each time it closes.
Bruce

 

[Guest]

Allen,

Don't know if you're still montioring this one or not.

We installed the Office updates right after you suggested doing so. Have
double-checked the updates for Server2003. All are current. They have been
monitoring while I've been on vacation.

Incidence of problems is reduced, but still there. Now about 1 out of 10
times. We run it three times each night on three different back ends. No
consistency on when it fails, but any subsequent jobs don't run after the
first failure. We check each morning, but kind of defeats purpose of
scheduling at night.

The SA is freaking, saying it's my program. I think it's the server because
it runs perfectly on WinXP Pro. Got to get this resolved, though, so do you
have any more suggestions?

Thanks,
Bruce

 

[Allen Browne]

Bruce, there's not anything specific to go on here, so I don't know what to
suggest.

I am not aware of a problem in Office XP that occurs only on Win Server
2003.

You could try following the (rather generic) steps below to see if you can
eliminate a corruption from the database.

We don't know what the database is doing when it crashes. If you are running
queries, we might be able to discuss the content of those, since there are
some scenarios that cause JET to crash.

General suggestions for removing possible corruption from an mdb:

1. Uncheck the boxes under:
Tools | Options | General | Name AutoCorrect
Explanation of why:
http://allenbrowne.com/bug-03.html

2. Compact the database to get rid of this junk:
Tools | Database Utilities | Compact/Repair

3. Close Access. Make a backup copy of the file. Decompile the database by
entering something like this at the command prompt while Access is not
running. It is all one line, and include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

4. Open Access (holding down the Shift key if you have any startup code),
and compact again.

5. Open a code window.
Choose References from the Tools menu.
Uncheck any references you do not need.
For a list of the ones you typically need in your version of Access, see:
http://allenbrowne.com/ser-38.html

6. Still in the code window, choose Compile from the Debug menu.
Fix any errors, and repeat until it compiles okay.

At this point, you should have a database where the name-autocorrect errors
are gone, the indexes are repaired, inconsistencies between the text- and
compiled-versions of the code are fixed, reference ambiguities are resolved,
and the code syntax is compilable.

If it is still a problem, the next step would be to get Access to rebuild
the database for you. Follow the steps for the first symptom in this
article:
Recovering from Corruption
at:
http://allenbrowne.com/ser-47.html

 

[Guest]

Thanks, Allen!

I'll go through what you suggested. I know that "Name Auto Correct" is
turned on. If it's Jet, it's when it tries to initialize it because the
lockup hits before Access even opens the initial form.

Anyway, we'll see what happens.

Thanks again, Allen.

Bruce

 

[Allen Browne]

Great news.

Sometimes the 2 copies of the VBA code get out of sync, so the text version
(what you see and edit) no longer matches the compiled version (what
actually executes.) The decompile instructs Access to dump the compiled
version. It then recreates it from the text, so the sync error is gone.

The decompile will often reduce the file size, especially (but not only)
when this kind of corruption occurs.

All the best.