Very Strange Database Phenomena!

L

Logo

We have a database at work where 5 managers enter data. Each entry is
automatically given an id # which is the primary key for the table. After
each mgr has finished entering their data, a report is printed of the
accounts in their region. This report is then used to verify numbers
reported at each account. So we have 5 reports printed on paper of our 5
regions. All is good.

Now its 9 days later, and we are using the reports to double check hours vs
our payroll company for our two week pay period (this was the first week of
the pay period).

Instead of going to my manager's office to retrieve the printed reports I
re-run them again and just use my computer display to double check that the
hours are correct we are sending to payroll. I find that we are missing one
complete region that we had confirmed 9 days earlier. I opened the table to
see if maybe it was "hiding" somewhere but there is no data whatsoever for
that region for that week.

Upon studying the printed reports, I see that id #'s for records in the
missing region have been assigned to records scattered about the other 4
regions! The missing region was probably printed maybe an hour before the
others.

How can this happen? I'm looking at physical printed proof that Access has
assigned a unique id # to 2 different records, for all the records of one
region, about 40-50 records in all.

We've used this database for a year with no problems whatsoever...
 
D

DW

How can this happen?  I'm looking at physical printed proof that Accesshas
assigned a unique id # to 2 different records,  for all the records of one
region, about 40-50 records in all.

We've used this database for a year with no problems whatsoever...

Did someone exit Access by hitting the x in the upper right hand
corner instead of file==========>exit?

That would give you this error.
 
L

Logo

--
Logo


DW said:
Did someone exit Access by hitting the x in the upper right hand
corner instead of file==========>exit?

That would give you this error.

.
That could easily be the case but it would have already happened at least
once this year then...no way we made it a whole year without that happening!
 
D

Dale Fye

If your "missing region" report was complete, DW's comment would not apply.
BTW, you can prevent people from closing a form using the X button. If you'd
like to know how, post back and I'll give you instructions.

How are you generating the Unique ID (is it an autonumber field, or some
number you generate manually or via code)? If generated by manually or via
code (which is what I suspect), when (what event) is this # being generated?
and what does the code look like?
 
L

Logo

It is an autonumber field.
--
Logo


Dale Fye said:
If your "missing region" report was complete, DW's comment would not apply.
BTW, you can prevent people from closing a form using the X button. If you'd
like to know how, post back and I'll give you instructions.

How are you generating the Unique ID (is it an autonumber field, or some
number you generate manually or via code)? If generated by manually or via
code (which is what I suspect), when (what event) is this # being generated?
and what does the code look like?
 
G

Gina Whipp

Logo,

Is it possible there was a network hiccup? Not that I have ever seen a set
of numbers get reassigned but it's a thought. Usually when Autonumbers get
used, even if used and deleted they don't *recover* so in theory your
scenario should be impossile... that said there is always a first time for
everything.

--
Gina Whipp
2010 Microsoft MVP (Access)

"I feel I have been denied critical, need to know, information!" - Tremors
II

http://www.regina-whipp.com/index_files/TipList.htm
 
L

Logo

That's pretty much my conclusion as well, but me being such an amateur it's
nice to know that an expert agrees...thank you!
 
T

Tom Wickerath

Hi Logo,

If this is a split database, as it likely should be since you stated that
various managers enter their data, have you verified that you were properly
linked to the production BE (Back-End) database, and not a test verification
database of the same exact structure (but perhaps not the same data)? Yup,
I've made that type of mistake in the past, and pulled what little hair I
have remaining out, trying to solve a PEBKAC (Problem exist between keyboard
and chair).

Another possibility is that one of your PHB's (Pointy Haired Bosses, aka
Dilbert's boss) replaced either the BE of a split database, or the entire
database (if unsplit), after they took it home to work on it. Thus, when they
replaced the copy, they wiped out a different manager's input.

It is *very* rare to have JET actually attempt to assign a duplicate
autonumber, which will fail when this field has a unique index (as a primary
key does). This JET error was fixed quite some time ago by a JET Service Pack
(if memory serves correctly, JET 4.0 SP3 and lower were suseptible to this
error). Anyway, it would be good to go around to all workstations to verify
that the latest service packs are installed:

Best Practices
How to keep a Jet 4.0 database in top working condition
http://support.microsoft.com/?id=303528

In particular, follow the three links:

Verify that the latest operating system service pack is installed
Verify that the latest Microsoft Jet service pack is installed and
Verify that the latest service pack for your version of Office is
installed

Also recommended: Install the latest version of MDAC (Microsoft Data Access
Components)
http://www.microsoft.com/downloads/...e3-c795-4b7d-b037-185d0506396c&DisplayLang=en


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
__________________________________________
 
T

Tom Wickerath

Did someone exit Access by hitting the x in the upper right hand
corner instead of file==========>exit?

That would give you this error.

Quite frankly, no, this would not produce such an error. If what you said
was true, believe me, just about every other posting in this newsgroup would
deal with lost and missing records, and MS Access would very likely not be
allowed in any company by the IT Departments that decide what software is
made available to employees to use.


Tom Wickerath
Microsoft Access MVP
http://www.accessmvp.com/TWickerath/
__________________________________________
 

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