Users claim data disappears

[Guest]

Have 10 Access 2000 dbs on separate LANs. On one site, users claim that data
just disappears. They have printed out student schedules based on the data,
but the data isn't there any more. Is there any way that data can simply
disappear without user intervention? When the db gives the "needs repair"
msg, I've noted that data input during that interval by users already in may
not be saved correctly, but there are no error msgs in this instance. I have
removed the delete permission for the table, but that doesn't keep them from
changing the data so they don't recognize it. I found info on how to capture
the date a record is changed and will implement on next update. Also, this
db's server is showing that the SNMP service has been down a number of times
(sometimes for hours) during the time the data supposedly disappears. Could
this be connected? I think it's user error, but need to eliminate anything
else.

 

[aaron.kempf]

MDB is a crappy database; don't trust MDB for anything.

i believe that under normal use; a MDB file will randomly lose data.

sorry.

better luck choosing a database; next time i would go for sql server

 

[Dirk Goldgar]

MDB is a crappy database; don't trust MDB for anything.

i believe that under normal use; a MDB file will randomly lose data.

Aaron, you're entitled to your point of view, but you're just plain
wrong.

 

[Dirk Goldgar]

"Not_A_Real_Programmer"

Have 10 Access 2000 dbs on separate LANs. On one site, users claim
that data just disappears. They have printed out student schedules
based on the data, but the data isn't there any more. Is there any
way that data can simply disappear without user intervention? When
the db gives the "needs repair" msg, I've noted that data input
during that interval by users already in may not be saved correctly,
but there are no error msgs in this instance. I have removed the
delete permission for the table, but that doesn't keep them from
changing the data so they don't recognize it. I found info on how to
capture the date a record is changed and will implement on next
update. Also, this db's server is showing that the SNMP service has
been down a number of times (sometimes for hours) during the time the
data supposedly disappears. Could this be connected? I think it's
user error, but need to eliminate anything else.

My first reaction was to wonder if the users have been entering data
that then doesn't meet the criteria being applied to select it -- so
they think it has mysteriously vanished, when actually it's still there
in the database.

My second reaction is to wonder about the offhand way you say, 'When the
db gives the "needs repair" msg ...'. If your databases are being
corrupted on a regular basis, you have a serious problem, and you ought
to find out what is corrupting them. It is certainly true that data
entered into a corrupted database can be lost.

Are your users opening the same networked .mdb files, or is each opening
his or her own copy of a front-end .mdb file, linked to a shared network
back-end .mdb? If everybody's directly opening the same, monolithic
database over the network, the database will be prone to corruption.

I don't know about the significance of the SNMP service failing, and
whether that signifies a network problem that could also be causing
corruption in the database. Access is very sensitive to network
glitches, and requires a solid network to avoid corruption.

 

[Guest]

Out trolling again today?

 

[Guest]

In order of likelihood from past experience.

1. They never actually put the data in there in the first place. Users lie.

2. Someone deleted or changed the data. Users lie.

3. The data is there but can't be found by the forms, reports, and queries
as they are now written.

4. The database is written badly with something like unbound forms not
saving the data.

5. Users are working in different database files. Make sure that they are
linked to the proper backend.

6. Actual database corruption; however, you should be seeing other problems.

7. Someone is replacing the database from backup files. Could this be what's
going on after your SNMP outages?

 

[Joseph Meehan]

Out trolling again today?

School must be out again.

 

[John Vinson]

School must be out again.

Or maybe Aaron's prescription ran out...

John W. Vinson[MVP]

 

[dbahooker]

good stuff john

did Microsoft tell you to belittle me?

it's an official smear campaign?

i speak the truth and you can screw yourself; mdb sissy

 

[Guest]

I believe the criteria is met because the users are able to exit the form and
print out the data. I'm a novice, but I would think they couldn't print it
if the records weren't released and therefore saved. For the "repair"
situation, we don't have the problems very often any more since we split the
dbs, got the users to exit properly, turned off op locks on the server, etc.
Of the 10 dbs, we've probably needed to run a repair about 5 times
altogether since the new versions went into production in August. The
NetAdmin would not set this one up to copy to the desktop, so we are using a
central mdw, be and fe on the server. Last year, he was copying it to the
desktop but said it's taking too long to run the script. Two years ago, I
located Tony Toews' utility to copy/update the fe to the desktop but the
NetAdmin won't use it. In the past, any time the db has corrupted, there was
strange behavior and new users couldn't get in. None of those symptoms with
this. The more I think about this, the more I think it's got to be user
error. If the data was saved to the point where it could be queried from a
different screen, and pulled up in a report, I don't see how it can just
disappear.

I have both the FE and BE set to compact on close. I thought that,
theoretically, when the last user exited the program, it should compact. (I
didn't have that problem last year because the FE always compacted on the
user's workstation.) On this db, I had to manually run the compact and
repair before it shrank back to normal size. Could this happen when users
don't log out of the db and network utilities that run at night disrupt the
session?

By the way, thanks for a "real" response to my question. Can't say as much
for others!

 

[Joseph Meehan]

it's an official smear campaign?

i speak the truth and you can screw yourself; mdb sissy

Spoken like a true troll.

BTW next computer class ask about those buttons called "Shift"

 

[Joseph Meehan]

Not_A_Real_Programmer wrote:
.....

By the way, thanks for a "real" response to my question. Can't say
as much for others!

Sorry I did not have a direct response to your question. I did not have
any answer for you. However I did want to make sure you, and others, would
not take the troll seriously. Even as transparent as he or she is, some
people might.

 

[Guest]

:

Sorry I did not have a direct response to your question. I did not have
any answer for you. However I did want to make sure you, and others, would
not take the troll seriously. Even as transparent as he or she is, some
people might.

I'm even less savvy on using this type of forum than I am using Access! I
couldn't figure out who was who. I guess the troll was the first guy whose
only input was how bad Access is? I've learned to ignore those people.
Sure, SQL is more powerful, but Access is what we have and can work quite
nicely in many instances. I chalk it up to their own prejudices. I'm a
59-year old woman who has never had a programming class in my life (although
I did take a logic class once). Using Access wizards, I wrote a program that
logs all student information, builds classes, enrolls students in classes,
produces class rosters for teachers, class schedules for students, progress
reports, report cards, caseloads for counselors, etc., etc., AND logs daily
attendance per class. I wonder if someone with no training (and no budget)
could do that in SQL? (If the answer to that is, "Sure," then don't tell
me. I don't want to feel stupid!)

 

[Dirk Goldgar]

"Not_A_Real_Programmer" <[email protected]>
wrote in message

I believe the criteria is met because the users are able to exit the
form and print out the data. I'm a novice, but I would think they
couldn't print it if the records weren't released and therefore
saved. For the "repair" situation, we don't have the problems very
often any more since we split the dbs, got the users to exit
properly, turned off op locks on the server, etc. Of the 10 dbs,
we've probably needed to run a repair about 5 times altogether since
the new versions went into production in August.

That still sounds like a very fragile situation, and makes me wonder if
there's something wrong with your network.

The NetAdmin would
not set this one up to copy to the desktop, so we are using a central
mdw, be and fe on the server.

So all your users are opening the same, server-based front-end? Hmm ...
not only could that give you an increased susceptibility to corruption,
I can think of a way it might -- just might -- account for your problem.

Access automatically saves the Filter and OrderBy property of forms when
you close them. Not the FilterOn property, but the filter criteria
string. If you have several people sharing the same front-end, that
means they could be overwriting each others' saved filters. If they
later try to apply those filters upon reopening the form, they won't
necessarily see the filtered data they expect.

Also, if your users are using several different versions of Access, you
can run into trouble with references. When each user opens the
database, Access is going to try to fix up the references to match that
user's installation of Office. I believe those adjusted references will
get saved in the shared front-end. Access is readily able to "upgrade"
the standard references, but not to downgrade them. So you could end up
with broken references in a heterogeneous Office environment. That
could cause a variety of problems with the database, though I wouldn't
think "missing data" would be one of them.

Last year, he was copying it to the
desktop but said it's taking too long to run the script. Two years
ago, I located Tony Toews' utility to copy/update the fe to the
desktop but the NetAdmin won't use it.

I have both the FE and BE set to compact on close. I thought that,
theoretically, when the last user exited the program, it should
compact. (I didn't have that problem last year because the FE always
compacted on the user's workstation.) On this db, I had to manually
run the compact and repair before it shrank back to normal size.
Could this happen when users don't log out of the db and network
utilities that run at night disrupt the session?

Maybe; I don't know. I think you could run into problems if a user has
a "dirty" form (or other modified, unsaved data) and something happens
to the network connection. I have no experience with that, though.

 

[Joseph Meehan]

:



I'm even less savvy on using this type of forum than I am using
Access! I couldn't figure out who was who. I guess the troll was
the first guy whose only input was how bad Access is? I've learned
to ignore those people. Sure, SQL is more powerful, but Access is
what we have and can work quite nicely in many instances. I chalk it
up to their own prejudices. I'm a 59-year old woman who has never
had a programming class in my life (although I did take a logic class
once). Using Access wizards, I wrote a program that logs all student
information, builds classes, enrolls students in classes, produces
class rosters for teachers, class schedules for students, progress
reports, report cards, caseloads for counselors, etc., etc., AND logs
daily attendance per class. I wonder if someone with no training
(and no budget) could do that in SQL? (If the answer to that is,
"Sure," then don't tell me. I don't want to feel stupid!)

You sound that someone with their feet on the ground and a good
attitude. Good Luck

 

[dbahooker]

Dirk you name to me how MDB is functional

compact and repair?
refresh, relink?

your baby database sucks balls and you guys are all wimps

MSDE is free and you guys are obsolete