Concerned about different Access versions--need serious help!

[Guest]

Greetings,

I am having a serious issue, of which I could lose my job in regards to it.
My company uses a program in Access (done in Visual Basic) to input data
entry. There have been issues with the programming here and there, but for
the most part the program has been usable. A monthly report gets churned out
to see the results of savings or losses, etc.

Suddenly, out of nowhere, the monthly reports are showing bizarre and
screwed up results, making it look as if I am putting the data entry in
wrong, and I know I am not. I am wondering this: The Access version I was
using all that time was 2002 SP3 (which I just found out recently). Right
now, I am unsure of the version they are using at work (sent an email to my
boss asking ASAP), but no question was ever raised by the programmer or
anyone else, as to this possibly being an issue. I wonder if what I am
putting into the system, then save to CD and they load up at work on their
computer, if it is a different version, that it might screw up what I
inputed, and henceforth screw up the data reports printed out????

It has already been proven the following:

1. A big chunk of "bills" I inputted, my boss said that a certain button of
Lost or Savings was not pressed, but when I checked my input at home, ALL
WERE PRESSED--there was not a single one like the way he said. Boggling.

2. When I fire up the program in Access, I get two errors, and I click OK
and start entering. Obviously, it isn't too good of programming if I START
with 2 errors right off the bat! I showed this to the people at
work--including the programmer--and it was ignored as something odd that
"just happens" and to "keep inputting." BUT...the one computer at work--used
by the programmer--oddly does not get the error when she fires up the
program! Could she possibly have a different version so it's not giving her
errors like it is mine???

3. Lastly proven was this: The program was churning out reports that were
CHANGING ON ITS OWN the numbers, percentages, etc. That is, they'd print out
a data report...wait five monutes, print out another one, and it would be
DIFFERENT in results!! Originally, the finger was pointed at me for the
screw up, but when the results changed on their own right there in front of
them, well, they then knew I wasn't to blame.

What is going on? My main concern is if I might have a different version of
Access than them, so what I input is being screwed up when converted to their
version...Is this possible? This is important to find out, as it could mean
my job. I don't mess with Access or Visual Basic so bear with me; it is not
my field, but I am smart enough to know various versions can mean various
results/errors. It's already been proven enough in the past that the program
used at work by the one girl, does not get weird errors that I do (such as
when I put in the month and year, some debugging option pops up, but not for
her!)...

Thanks in advance for any help!!

 

[Joseph Meehan]

Greetings,

I am having a serious issue, of which I could lose my job in regards
to it. My company uses a program in Access (done in Visual Basic) to
input data entry. There have been issues with the programming here
and there, but for the most part the program has been usable. A
monthly report gets churned out to see the results of savings or
losses, etc.

Suddenly, out of nowhere, the monthly reports are showing bizarre and
screwed up results, making it look as if I am putting the data entry
in wrong, and I know I am not. I am wondering this: The Access
version I was using all that time was 2002 SP3 (which I just found
out recently). Right now, I am unsure of the version they are using
at work (sent an email to my boss asking ASAP), but no question was
ever raised by the programmer or anyone else, as to this possibly
being an issue. I wonder if what I am putting into the system, then
save to CD and they load up at work on their computer, if it is a
different version, that it might screw up what I inputed, and
henceforth screw up the data reports printed out????

It has already been proven the following:

1. A big chunk of "bills" I inputted, my boss said that a certain
button of Lost or Savings was not pressed, but when I checked my
input at home, ALL WERE PRESSED--there was not a single one like the
way he said. Boggling.

2. When I fire up the program in Access, I get two errors, and I
click OK and start entering. Obviously, it isn't too good of
programming if I START with 2 errors right off the bat! I showed
this to the people at work--including the programmer--and it was
ignored as something odd that "just happens" and to "keep inputting."
BUT...the one computer at work--used by the programmer--oddly does
not get the error when she fires up the program! Could she possibly
have a different version so it's not giving her errors like it is
mine???

3. Lastly proven was this: The program was churning out reports
that were CHANGING ON ITS OWN the numbers, percentages, etc. That
is, they'd print out a data report...wait five monutes, print out
another one, and it would be DIFFERENT in results!! Originally, the
finger was pointed at me for the screw up, but when the results
changed on their own right there in front of them, well, they then
knew I wasn't to blame.

What is going on? My main concern is if I might have a different
version of Access than them, so what I input is being screwed up when
converted to their version...Is this possible? This is important to
find out, as it could mean my job. I don't mess with Access or
Visual Basic so bear with me; it is not my field, but I am smart
enough to know various versions can mean various results/errors.
It's already been proven enough in the past that the program used at
work by the one girl, does not get weird errors that I do (such as
when I put in the month and year, some debugging option pops up, but
not for her!)...

Thanks in advance for any help!!

I suggest you may try making a copy of the original and then trying to
run the "repair" function under tools on the copy.

Good Luck

 

[Guest]

Hi NightowlMania,

My suggestion is to check for missing references. Here are two good articles
on the subject:

Solving Problems with Library References (Allen Browne)
http://allenbrowne.com/ser-38.html

Access Reference Problems (Doug Steele)
http://www.accessmvp.com/djsteele/AccessReferenceErrors.html

Open the database and then press ALT F11 to open the Visual Basic Editor
(VBE). Click on Tools > References to check for any that are marked as
MISSING. If all references seem to be in place, then you may still need to
refresh the references list. This is done by making a change in the selected
references. The easiest way is to temporarily add a new reference, click on
OK to dismiss the references dialog, and then go back in and remove the newly
added reference.

After closing the references dialog, click on Debug > Compile ProjectName.
Does the code compile without any errors? Do the code modules include
"Option Explicit" as the second line of code at the top?

Always Use Option Explicit
http://www.access.qbuilt.com/html/gem_tips.html#VBEOptions


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

:

Greetings,

I am having a serious issue, of which I could lose my job in regards to it.
My company uses a program in Access (done in Visual Basic) to input data
entry. There have been issues with the programming here and there, but for
the most part the program has been usable. A monthly report gets churned out
to see the results of savings or losses, etc.

Suddenly, out of nowhere, the monthly reports are showing bizarre and
screwed up results, making it look as if I am putting the data entry in
wrong, and I know I am not. I am wondering this: The Access version I was
using all that time was 2002 SP3 (which I just found out recently). Right
now, I am unsure of the version they are using at work (sent an email to my
boss asking ASAP), but no question was ever raised by the programmer or
anyone else, as to this possibly being an issue. I wonder if what I am
putting into the system, then save to CD and they load up at work on their
computer, if it is a different version, that it might screw up what I
inputed, and henceforth screw up the data reports printed out????

It has already been proven the following:

1. A big chunk of "bills" I inputted, my boss said that a certain button of
Lost or Savings was not pressed, but when I checked my input at home, ALL
WERE PRESSED--there was not a single one like the way he said. Boggling.

2. When I fire up the program in Access, I get two errors, and I click OK
and start entering. Obviously, it isn't too good of programming if I START
with 2 errors right off the bat! I showed this to the people at
work--including the programmer--and it was ignored as something odd that
"just happens" and to "keep inputting." BUT...the one computer at work--used
by the programmer--oddly does not get the error when she fires up the
program! Could she possibly have a different version so it's not giving her
errors like it is mine???

3. Lastly proven was this: The program was churning out reports that were
CHANGING ON ITS OWN the numbers, percentages, etc. That is, they'd print out
a data report...wait five monutes, print out another one, and it would be
DIFFERENT in results!! Originally, the finger was pointed at me for the
screw up, but when the results changed on their own right there in front of
them, well, they then knew I wasn't to blame.

What is going on? My main concern is if I might have a different version of
Access than them, so what I input is being screwed up when converted to their
version...Is this possible? This is important to find out, as it could mean
my job. I don't mess with Access or Visual Basic so bear with me; it is not
my field, but I am smart enough to know various versions can mean various
results/errors. It's already been proven enough in the past that the program
used at work by the one girl, does not get weird errors that I do (such as
when I put in the month and year, some debugging option pops up, but not for
her!)...

Thanks in advance for any help!!

 

[Guest]

It is not the Access Version.

It might be the way Windows, Access and the program
are installed on your PC. This often makes the program
unusable on another PC, but this does not normally cause
data errors.

2. When I fire up the program in Access, I get two errors, and I click
and start entering. Obviously, it isn't too good of programming if I

What are the two errors?

a data report...wait five monutes, print out another one, and it would
DIFFERENT in results!! Originally, the finger was pointed at me for

You need to get that straightened out. There is no point looking
for data entry errors if the reports don't work.

Using a different Access version will not cause data errors. If the
program in installed on a different PC, sometimes there are problems,
but the problems are not normally data errors, and the problems
are not specifically caused by the Access version.

It is very rare to get any kind of data error, and when there is
a data error, it is not caused by the Access version. You will
have to look for more complex explanations.

(david)

 

[TC]

If your job is really at risk over this, and you are not responsible
for programming the database, then, you have a political problem - not
a technical one!

Make sure you get your boss on side. Perhaps you should say that you
feel uncomfortable doing the data entry after the system has given two
errors. "I'm not sure what those errors mean. Maybe they're something
to do with the problems we're having? I'm not a programmer, I just
don't know. The programmer has said to ignore them."

That would not be unfair to the programmer, or sneaky behaviour on your
part. It would be a sensible strategy for protecting yourself by
keeping your boss in the picture.

HTH,
TC [MVP Access]

 

[Joan Wild]

I agree with David on this. Data errors are not caused by using different
versions of Access.

You said, "I wonder if what I am putting into the system, then save to CD
and they load up at work on their computer" might be the source of the
problem.

Just how are they 'loading it up at work'? Are they just opening your file,
or are they importing/updating your data. I would look into this aspect as
bit more

 

[Guest]

Hi David,

While I will agree with you that 99.5% of the time it is not the version of
Access, one should never make absolute statements. In fact, I diagnosed a
problem three years ago (January, 2003) where the results of a query were
different after converting an application from Access 97 to Access 2000.

It turned out that in this particular case, some of the data included
non-printing spaces. The LIKE operator in Access 97 (JET 3.5) versus Access
2000 (JET 4.0) filters non-printing spaces differently when they are embedded
in a field with a data value.


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

:

It is not the Access Version.

It might be the way Windows, Access and the program
are installed on your PC. This often makes the program
unusable on another PC, but this does not normally cause
data errors.

2. When I fire up the program in Access, I get two errors, and I click
and start entering. Obviously, it isn't too good of programming if I

What are the two errors?

a data report...wait five monutes, print out another one, and it would
DIFFERENT in results!! Originally, the finger was pointed at me for

You need to get that straightened out. There is no point looking
for data entry errors if the reports don't work.

Using a different Access version will not cause data errors. If the
program in installed on a different PC, sometimes there are problems,
but the problems are not normally data errors, and the problems
are not specifically caused by the Access version.

It is very rare to get any kind of data error, and when there is
a data error, it is not caused by the Access version. You will
have to look for more complex explanations.

(david)

 

[Guest]

Ok, here are some more notes regarding my issues: First, Joan, to answer
your question...They give me the mdb(?) file on CD and then I double-click on
it, which makes it auto-open with Access. I then get the infamous errors
(which I'm putting below), and put in my data. I then exit out, which makes
it auto-save, and burn it onto CD. Now, first, I copy and paste the mdb file
on my desktop; i.e., I do not work from the CD. Secondly, I then rename the
file before saving it to give back to them the completed work. They then pop
in the CD and copy and paste into a folder that has an archive of a bunch of
dated mdb files. We just keep using the newest dated one to work in. Older
ones are kept in a folder just in case, I guess.

Now, onto the errors: When I open up the program in Access, I click on the
designated button to start putting in data (something like "Add Data"). This
is the 1st error I receive:

Your Microsoft Access database or project contains a missing or broken
reference to the file 'ccrpbds6.dll' version 1.1. *To ensure your database
or project works properly, you must fix this reference. *To learn how to fix
this reference, click Help.

2nd error (after I click OK, which I was told to do by the boss and
programmer):
Your Microsoft Access database or project contains a missing or broken
reference to the file 'JDataEncrypter.dll' version 1.0. *To ensure your
database or project works properly, you must fix this reference. *To learn
how to fix this reference, click Help.


Obviously, it is unnerving that, right off the bat, I have two programming
errors, and am told to ignore it and keep putting in data! Here is a 3rd
error I get:

Table 'TempMSysAccessObjects' already exists. <--This error comes up even
before I click on the button to start putting in data. I then click OK, and
click on the button to begin my work, and then get the previous two dll
errors. --sigh--


There are other little things that mess up, too, but those are the main
ones.

Could those above things be messing up what I input?

Thanks for any help!!

 

[Guest]

Hi Nightowl,

For your two reference related errors, please see the following articles:

Solving Problems with Library References (Allen Browne)
http://allenbrowne.com/ser-38.html

Access Reference Problems (Doug Steele)
http://www.accessmvp.com/djsteele/AccessReferenceErrors.html

For your Table 'TempMSysAccessObjects' already exists error, please see the
following Knowledge Base (KB) article:

PRB: "Table 'TempMSysAccessObjects' Already Exists" Error Message May Occur
While Using the Compact and Repair Database Utility
http://support.microsoft.com/?id=818099

Obviously, it is unnerving that, right off the bat, I have two programming
errors, and am told to ignore it and keep putting in data!

I agree. It sounds like your company has hired a hack who professes to be a
programmer! These types of errors should be investigated and resolved, not
simply ignored.

There are other little things that mess up, too, but those are the main ones.

Why am I not surprised....your programmer chooses to ignore errors instead
of fixing them.

Could those above things be messing up what I input?

Possibly. However, it's hard to say without knowing more about the design of
this database.

Here is another KB article that is worth reading (and forwarding to your
programmer):

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


Good Luck,
Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

:

Ok, here are some more notes regarding my issues: First, Joan, to answer
your question...They give me the mdb(?) file on CD and then I double-click on
it, which makes it auto-open with Access. I then get the infamous errors
(which I'm putting below), and put in my data. I then exit out, which makes
it auto-save, and burn it onto CD. Now, first, I copy and paste the mdb file
on my desktop; i.e., I do not work from the CD. Secondly, I then rename the
file before saving it to give back to them the completed work. They then pop
in the CD and copy and paste into a folder that has an archive of a bunch of
dated mdb files. We just keep using the newest dated one to work in. Older
ones are kept in a folder just in case, I guess.

Now, onto the errors: When I open up the program in Access, I click on the
designated button to start putting in data (something like "Add Data"). This
is the 1st error I receive:

Your Microsoft Access database or project contains a missing or broken
reference to the file 'ccrpbds6.dll' version 1.1. *To ensure your database
or project works properly, you must fix this reference. *To learn how to fix
this reference, click Help.

2nd error (after I click OK, which I was told to do by the boss and
programmer):
Your Microsoft Access database or project contains a missing or broken
reference to the file 'JDataEncrypter.dll' version 1.0. *To ensure your
database or project works properly, you must fix this reference. *To learn
how to fix this reference, click Help.

Obviously, it is unnerving that, right off the bat, I have two programming
errors, and am told to ignore it and keep putting in data! Here is a 3rd
error I get:

Table 'TempMSysAccessObjects' already exists. <--This error comes up even
before I click on the button to start putting in data. I then click OK, and
click on the button to begin my work, and then get the previous two dll
errors. --sigh--

There are other little things that mess up, too, but those are the main
ones.

Could those above things be messing up what I input?

Thanks for any help!!

 

[Guest]

Hi.

It's extremely unlikely that the problem is due to the version of Access you
are using for data entry. The common problem you've described is much more
likely to be a database design error or database application error (such as
the one Tom Wickerath described).

Suddenly, out of nowhere, the monthly reports are showing bizarre and
screwed up results

BIG Red flag: This is the first week of the new year, when queries with
date problems most often reveal themselves. The first thing to check is the
underlying queries for these reports. Check the WHERE clauses and HAVING
clauses for dates, especially ones that use 2005 instead of dynamically
determining the current year to use for the criteria. Next thing to check
are the underlying queries for the forms you are using for data input for the
same type of date problems.

Are you using the same version of the VB application and the database as the
office is? They may have upgraded to fix bugs or add features but forgot to
send the latest versions to you, so you may have old versions. And you
haven't altered the original versions they gave you. Right?

making it look as if I am putting the data entry in
wrong, and I know I am not.

What type of data input errors are we examining here? Do you type 486 in
the form's text box and the record in your table clearly shows 17 for this
column? (An update problem.) Or does the wrong record receive this 486?
For example, you typed 486 into the record for blue baseball caps, but
instead it's assigned to the record for footballs. (A design or logic
problem.) Or does the record show a quantity of 486 for blue baseball caps
in your database file's table, but the same record shows 17 when the boss
looks at his copy of the same table on the office computer? (A data
transfer, append, or update problem.)

1. A big chunk of "bills" I inputted, my boss said that a certain button of
Lost or Savings was not pressed, but when I checked my input at home, ALL
WERE PRESSED--there was not a single one like the way he said.

Check how your boss is getting the data from your file into his database.
It may be a bad import of new data or failure to import the new data -- so he
only sees old data, but blames you. Use of linked Excel spreadsheets for
data input or data retrieval, or use of disconnected recordsets might also
enable your boss to see data other than what you've most recently typed in.

2. When I fire up the program in Access, I get two errors, and I click OK
and start entering. Obviously, it isn't too good of programming if I START
with 2 errors right off the bat!

This type of thinking will get you into trouble with the application
developer, which is exactly the opposite of what you want. You want the
application developer to be on your side so that you work together to
determine what's going wrong, because neither of you has all the facts or
skills needed (or else you would have already found the cause by now).

BUT...the one computer at work--used
by the programmer--oddly does not get the error when she fires up the
program! Could she possibly have a different version so it's not giving her
errors like it is mine???

Computer configuration discrepancies and missing library references are
common reasons why the user experiences data application errors while the
application developer does not. If you make sure that you are both using the
same version of the OS, Access, Jet, and MDAC (including service packs), and
all files use the same paths (meaning your computer is a clone of theirs or
theirs is a clone of yours), then you most likely won't see what she's not
seeing. If you can't get this degree of sameness, the most important ones to
match are Jet and MDAC (including service packs), and lastly the OS
(including service packs).

3. Lastly proven was this: The program was churning out reports that were
CHANGING ON ITS OWN the numbers, percentages, etc.

This common data anomoly is a symptom of incorrect database design and/or
database application errors. The most likely cause of these data
inconsistencies is in how the office retrieves the data that you have input,
because it’s a different method than what is used to input the data (i.e., a
sorted query vs. an unsorted table, or just an incorrect query such as one
that joins on NULL’s or one that only manipulates one field in a composite
key). And the most likely cause of this is non-normalized tables, incorrect
queries, incorrect VBA procedures, the lack of unmalleable primary keys, or
using Reserved words as names for tables, queries, or columns.

So, after checking the date criteria for the reports' and data input forms'
underlying queries, check for the following:

1.) All of the tables are normalized; and
2.) All of the tables have primary keys whose values never change; and
3.) If the primary key is a composite key, then all columns in the key are
handled in the same way as a group (for example, joining on both columns of a
composite key in a query instead of joining on only one of the columns); and
4.) If the queries use multiple tables, then don't use Cartesian joins
(only use ANSI SQL-92-compliant joins); and
5.) If the queries use multiple tables, then the joins are on columns that
do not allow NULL values; and
6.) Those queries where sorting is depended upon are sorted in the same way
for data input and for retrieving the data; and
7.) No table, query, or column uses illegal characters in its name; (Use
only alphanumeric characters and the underline character. If enclosing
brackets are required around the name, then you know that an illegal
character or a Reserved word was used for the name.) and
8.) No table, query, or column uses any Reserved word as its entire name; and
9.) Calculated columns (either in queries or in bound controls) are
calculated correctly; and
10.) The data is not input directly into linked Excel spreadsheets, but
actual tables in a database (Jet, SQL Server, Oracle, et cetera); and
11.) If disconnected recordsets are being used in the VB application for
data input, ensure that all data in every record updates the table and every
error is caught, not just glossed over with an "On Error Resume Next" line of
VB code.

when I put in the month and year, some debugging option pops up, but not for
her!)...

If it were my job on the line and this was a job I wanted to keep, then I'd
be helping with that debugging myself. The application developer can't help
you if she can't duplicate the error to troubleshoot it. Get her on the
phone to step you through it and be her eyes.

I don't mess with Access or Visual Basic so bear with me; it is not
my field

If you read the information I've offered and thought, "I have no idea what
any of this stuff means," then you either need to find out or get someone who
does -- if your job is dependent upon this issue. The VB application
developer and the Access database developer are your best bets for help in
resolving this matter. Being cooperative instead of pointing fingers will
put you in the best light where your boss is concerned.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
See http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

- - -
If my answer has helped you, please sign in and answer yes to the question
"Did this post answer your question?" at the bottom of the message, which
adds your question and the answers to the database of answers. Remember that
questions answered the quickest are often from those who have a history of
rewarding the contributors who have taken the time to answer questions
correctly.

 

[Guest]

To add to what others have offered:

Your Microsoft Access database or project contains a missing or broken
reference to the file 'JDataEncrypter.dll' version 1.0.

I don't know how important those missing libraries are, but the name of this
user-defined library prompts me to speculate that if the VB application
encrypts the data you input and must use this library that is either missing,
isn't registered, or is the wrong version, then the data is not encrypted
when it's saved to the table. And when the office's version later decrypts
what hasn't been encrypted, this would produce bizarre results in reports.

If this is the case, then it's your fault for having a faulty library
reference on your computer and for listening to the boss and developer on
what to do about it. ;-)

(It's best to live by only two rules when one wants to continue to work for
someone else:

Rule #1: The boss is always right.
Rule #2: In case the boss is wrong, see rule #1.)

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
See http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.

- - -
If my answer has helped you, please sign in and answer yes to the question
"Did this post answer your question?" at the bottom of the message, which
adds your question and the answers to the database of answers. Remember that
questions answered the quickest are often from those who have a history of
rewarding the contributors who have taken the time to answer questions
correctly.

 

[TC]

But Tom, how are those technical references going to help her? She say
she's not the programmer. She says the programmer has told her to
ignore the errors. Surely you're not expecting her to fix the
programming problems herself?

I say she is being set up for a fall. She is not the programmer, and
she should not be expected to do the progammer's job. How has the
programmer managed to shift this monkey off his/her back, and onto the
data entry operator's?

OP, can't you take the approach that this is a programming problem & it
is the programmer's problem to fix it?

Cheers all,
TC [MVP Access]

 

[Guest]

Thanks TC...I concur. I want to point out that the collection of responses
has helped me a great deal, because it sets up a case in my defense. I have
done programming before (just not Visual Basic) and I have two brothers that
are high-end programmers. Both have done some Visual Basic. The point is
that no matter what programming each of us has done, we all can agree that
when errors aren't fixed, you're always taking a risk that it will cause a
problem. Error prompts don't pop up for no reason or for eyecandy; they pop
up for a reason. And I was told to ignore them, so that raised a huge alarm
to me. These errors were from around 3 months ago, and they haven't been
fixed, either out of laziness, deliberate ulterior motives, or the person
doesn't know how to fix them, but is afraid to admit it, so it falls on me as
the problem...and she saves her butt.

For the record, there is a time in the past, when I was approached on the
fact that a data report was showing I didn't put in a certain truck company's
bills correctly. I was asked if I knew what I was doing (since I was
relatively new--only 2 months if that), and I stressed that "Yes, I know how
to do that truck company in terms of data input, rules, etc." They gave me a
cheatsheet anyway, which was somewhat condescending, because they didn't look
into the issue further yet, and ignored my answer (which had specific info to
prove that I did indeed know this company). At some point, they looked into
the file (database) and found out I did put everything in right! They were
like, "Oh... you did do it right...how strange..." and yet the data report
was screwed up.

So, the bottom line is this has happened before, yet they act as if it
couldn't possibly happen again. How foolish to think that way. I truly am
convinced the girl that assists the programmer, has it in for me. I won't
get into it too much, but basically she put in her "two weeks notice" five
months ago. She is still lingering around, but was supposed to move with her
boyfriend back home, two hours away. I suspect she can't find a new job out
there (it's a supersmall town), so she is trying to get back in the place,
and bring her boyfriend with her (I have his old job, mind you--he quit, too,
at the same time with her).

But despite that, the point is there have been technical issues before, so
it shouldn't be a shock for there to be again. My two brothers are
programmers, and I called them and asked them their opinion. They feel it
sounds like technical issues/bad programming. I have been on computers for
20 years, and this data entry isn't rocket science; it's actually kinda easy
to learn, and I've been doing it for 5 months now. If I was so bad, then why
didn'te the data reports show bad mistakes the first 2 months (the only ones
were the small amount of what I mentioned earlier, and they found out it
wasn't me)? Those came out fine! But coincidentally, when I started getting
the two errors popping up when I'd fire up the program, that was how far back
they printed data reports (the secretary forgot to print them monthly so they
got backed up--another mistake to make), and wouldn't ya know--the data
reports are screwing up bad, right at the same time the two errors started
showing on my screen! Hmm...

I could blab on and on, but tomorrow I go in and say my side of it all. I
hope I am prepared; I think I am. I will post again with the verdict.

But Tom, how are those technical references going to help her? She say
she's not the programmer. She says the programmer has told her to
ignore the errors. Surely you're not expecting her to fix the
programming problems herself?

I say she is being set up for a fall. She is not the programmer, and
she should not be expected to do the progammer's job. How has the
programmer managed to shift this monkey off his/her back, and onto the
data entry operator's?

OP, can't you take the approach that this is a programming problem & it
is the programmer's problem to fix it?

Cheers all,
TC [MVP Access]

 

[TC]

Ok, good luck! We'll all be keen to hear the outcome. Hopefully the
monkey will leap back onto the programmer's back.

Cheers,
TC [MVP Access]

 

[Guest]

Hi TC,

While Nightowl may not be a programmer, I believe the two reference related
papers I cited (Allen Browne and Doug Steele) are written in easy enough
language that she could explore the possibility of missing references. Since
the database is already on CD, she has a handy backup copy available in case
anything goes wrong.

To Nightowl: If the the girl that assists the programmer and her boyfriend
manage to squeeze you out of this job, consider it a blessing. You probably
don't want to try to make a career out of a small company who's management
points fingers first, before looking further into problems, and who allows
their programmer to shrug off errors. While I'm not the evangelical type,
I'll just add that the Lord works in mysterious ways. This company will
likely become a statistic, added to the list of business that fail.


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

:

But Tom, how are those technical references going to help her? She say
she's not the programmer. She says the programmer has told her to
ignore the errors. Surely you're not expecting her to fix the
programming problems herself?

I say she is being set up for a fall. She is not the programmer, and
she should not be expected to do the progammer's job. How has the
programmer managed to shift this monkey off his/her back, and onto the
data entry operator's?

OP, can't you take the approach that this is a programming problem & it
is the programmer's problem to fix it?

Cheers all,
TC [MVP Access]

 

[sebt]

To add my thoughts to the other contributions:

The report figures are wrong. This is either because the base-level
data is wrong, or because the report processing is wrong. But you can
_never_ assume that because a report shows unexpected results, it must
be because the base-level data isn't correct. I think that, out of the
100s of times I've been asked to look into unexpected report figures,
it's turned out to be a problem with the base data in about 2 cases.
In those cases I was able to bring up the base-level record on screen
in front of the data input guys as direct evidence ("these columns are
blank, but the paper forms says 123456, 343523, 235234 etc for this
value"), so that we could agree that there was a problem. The problem
was (and should always be, if things are run right - barring occasional
input errors which are inevitable) that the data input guys didn't
understand the input screen, which was brand new.

The point of this is that:
1. While anyone doing data-entry should make sure that they understand
exactly how the screen works and what they're supposed to type in,
genuine misunderstandings do happen: it's not good practice for the
programmer/system owner to just _assume_ that data input is going OK,
and then months later to suddenly realise that there's a "problem".
2. As far as I can tell from your posts you have never been given any
direct evidence that you've input the wrong data. Without that direct
evidence, my view would be that it's not your problem - there's so much
that can go wrong between _correct_ data and _incorrect_ aggregated
figures on a report.
3. As a programmer I've found that report figures are always the
politically most difficult part of an application - there's a tendency
for some managements to just say "these figures are WRONG" and blame
everyone in sight, without giving any more information that might help
to diagnose the problem. Sometimes it's turned out that the figures
were actually correct, they just weren't the figures that management
would have preferred to see...

So I agree with the earlier post that this is a political problem. You
mentioned that you've done programming before. Are you able to view
the base Access tables that your data goes into and understand what
should go where? (I assume you're doing the data input on forms).
This would at least give you the reassurance that when you type 123 on
a form it goes to the right place - whatever happens at the reporting
stage.
Work with the programmer if you can - if this isn't possible, getting
an understanding of the Access tables should give you some backup to
hold your own against accusations that you input things wrong.

Good luck!


Seb

 

[Guest]

Verdict:

Well guys, I got fired. The funny part is, my boss had told me a couple
days prior that he wasn't looking to fire anyone. My buddy replied (when I
told him), "Geez, if he said he wasn't gonna fire anyone, and then does fire
you, that b*tch must've done a number on the boss!" lol Obviously.

I walked in with a folder of stuff to show. The thing is, I had already
sent him a big email, stating an outline of the proof I had, showing that it
might not be something I did. You see, I've kept an open mind about this; I
have fully admitted and been content with "Hey, if I screwed things up, then
so be it--I am adult enough to accept it and be let go." But I also knew the
logic that I am so comfortable around computers, and have a wide array of
knowledge regarding them (Photoshop, Flash, Publisher, HTML, etc.), and
learned and understood the way the data was to be put in, that I just
couldn't have messed up the data entry that bad. So, I kept an an open mind
of what could be causing it. My boss, however, did not.

He claimed to keep an open mind, and--the day of my meeting with him
(Tues)--he said, "We're not pointing any fingers here..." Um, ok. Yes you
are. It was his nice way of avoiding that I was the one everybody assumed
screwed everything up, because why would I get fired? Duh! He then used
this smooth tactic to lower the severity of the blow on me, with "The blame
is on me. It's my fault for being so trustworthy." Well, that's a cutdown
on me, that he trusted I was doing my job, and "I wasn't," apparently. He is
a nice guy, but is terribly afraid to confront people with things. Worse, he
is completely wrapped around this girl's finger. He sees her as this
demigod, basically. You hafta understand that my boss isn't the brightest
bulb on computers, and he fully admits that. That said, if you do anything
trivially intelligent on a PC, he is enamored with your abilities! lol For
example, he asked me how to format something (which we all know is simple).
I showed him, and he stared at me with this look of, "WOWWWWWW! and replied,
"How awesome! Thaaaaanks!!"

Ok, so anyway, he had a pile of reports, exemplifying the apparent errors,
highlighted. He did a quick run of what was screwed up. Then he said, "And
if there's anything you have questions on, Rachel will step forward and
answer them for you." I knew that (a) he relied on her too much, and (b) he
was convinced I was the culprit, and he had it set in his mind his decision.
I was also kinda annoyed that the broad was in the next room (no closed
doors), pretending to work (she was listening in the whole time, cuz one time
she interrupted me while I was talking and stated some stuff). I feel that
if she wanted to be a part of the conversation/meeting, she should've walked
her butt to the conference room (which I thought deserved privacy) and sat
with us. Instead, she was yelling from another room, all unprofessionally
and rude-like. But my boss, yet again, favors her, and I think it was
unprofessional for him to have her hearing his firing of me. I just think
something like that should be kept private...but I am not surprised.

Anyway, he asked if I had any questions, and I told him I was listening for
now (I was very calm and professional), and then he continued, of which he
then stated he had to protect his company, so he had to let me go. I didn't
put up a fight, because I knew--just knew--he was too brainwashed by Rachel.
I walked to my old office, where I put my stuff down, and waved the folder of
info in my hand, mumbling, "So much for this..." He blinked and stared,
saying, "W-what's that?" Well, he already knew what it was--I told him
multiple times that I was bringing in evidence that I might not be to blame.
He was just afraid to review it and see a big argument ensue with Rachel, his
"precious (say with that voice on LOTR--lol)." I replied, "Oh don't worry
about this now. The decision has been made. Good luck with your company,"
and I shook his hand and smiled.

By the way, her boyfriend didn't waste ANY time being back in the game. The
dirt hadn't even been put on my coffin, and he had already taken over my
office. My desktop image was changed from Southpark to some jet fighter
plane, etc. Didn't waste any time, did they?...Go figure....But oh
noooooooooo, I wasn't sabotaged. Pfft.

But I see it as a blessing in disguise, too. I am annoyed, yes, that I
couldn't shove in her face some things (she always thought she was so above
everybody in every aspect; always had a very condescending attitude), and
bring her off her high horse, but I am also glad I won't have to deal with
the (a) naivety of my boss, and (b) the snottiness of this broad.

I realize I am venting and going off track of the purpose of this forum
(i.e., should be regarding Access/VB questions), but you guys have helped me
through this, and so I kinda felt like I could trust venting about the BS.
lol

Thanks again for all your help, albeit it was in unknowing vain, but also a
blessing resulting in not having to deal with this job anymore.

--Kris

 

[Tony Toews]

Well guys, I got fired.

Good for you. That was a boss from hell.

Ok, so anyway, he had a pile of reports, exemplifying the apparent errors,
highlighted. He did a quick run of what was screwed up. Then he said, "And
if there's anything you have questions on, Rachel will step forward and
answer them for you." I knew that (a) he relied on her too much, and (b) he
was convinced I was the culprit, and he had it set in his mind his decision.
I was also kinda annoyed that the broad was in the next room (no closed
doors), pretending to work (she was listening in the whole time, cuz one time
she interrupted me while I was talking and stated some stuff). I feel that
if she wanted to be a part of the conversation/meeting, she should've walked
her butt to the conference room (which I thought deserved privacy) and sat
with us. Instead, she was yelling from another room, all unprofessionally
and rude-like. But my boss, yet again, favors her, and I think it was
unprofessional for him to have her hearing his firing of me. I just think
something like that should be kept private...but I am not surprised.

Very, very unprofessional of him. Exceedingly so.

By the way, her boyfriend didn't waste ANY time being back in the game. The
dirt hadn't even been put on my coffin, and he had already taken over my
office. My desktop image was changed from Southpark to some jet fighter
plane, etc. Didn't waste any time, did they?...Go figure....But oh
noooooooooo, I wasn't sabotaged. Pfft.

Geez, that's so stupid.

But I see it as a blessing in disguise, too.

Agreed. He's an idiot.

I realize I am venting and going off track of the purpose of this forum
(i.e., should be regarding Access/VB questions), but you guys have helped me
through this, and so I kinda felt like I could trust venting about the BS.
lol

Thanks, it's sad hearing about your particular situation but the mere
fact that you came here originally asking questions about how to fix a
problem tells us a lot about you. You deserve better.

Thanks again for all your help, albeit it was in unknowing vain, but also a
blessing resulting in not having to deal with this job anymore.

Best wishes for the future. Please come back in the future if you
have some more problems.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm

 

[Guest]

Hi Kris,

I'll second everything that Tony wrote. You most certainly do deserve better.


Tom

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html

 

['69 Camaro]

Hi, Kris.

I'm sorry to hear you lost your job, but there's a silver lining here. You
no longer have to work for a bad boss who was extremely unprofessional in
the way he handled your firing (and probably unprofessional in other ways,
too). You now have an opportunity to go find a great boss to work for (or
maybe strike out on your own), and find a happier work environment.

Bad managers shouldn't be rewarded with good employees. The bad boss got
what he deserves: the calculating, snotty employee and her boyfriend - and
a database application that wasn't built correctly. Now the boyfriend is
going to have to explain the "errors" he supposedly input. Eventually, the
snotty employee will probably come to his rescue (if she can ever figure out
what's wrong), but in the meantime the boyfriend is going to be on the hot
seat.

And in case the boss isn't the owner of the company (but it sounds like he
is), he's going to have to explain to his superiors why there are still
errors in the reports - even after he fired the one who supposedly made
them. In case the boss is the owner, then he's going to have to make
business decisions that rely on these faulty reports. He's going to be
second-guessing himself, wondering whether the report he's currently looking
at is correct or not. And eventually he'll make poor business decisions
based on incorrect data in these reports, which will hinder his company.
The blame will go to his employees, not where it belongs, with the decision
maker. But at least he won't be able to point the blame at you, because you
won't be there.

Overall, I'd say you're better off not working there anymore. Now go get
the better job that you deserve.

Good luck to you.

Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips and tutorials.
See http://www.Access.QBuilt.com/html/expert_contributors2.html for contact
info.