Application-Defined or Object-defined Error on Report Wizard

Question

Ok, so I have a database that I have set up for tracking people who apply to volunteer for my work (which works with volunteers a lot) There are these tables that I have set up

Voluntermatch - where their initial information is entered, and their application is reviewed to see if they qualify to volunteer. 

Interview - The volunteer is sent to the site and the site either accepts them or rejects them. 

References - Once a site has accepted them, we have to check their references, and mark the date they are sent to orientation, date they attend orietnation, and the date that their background check, if required, comes back and if it's accepted or rejected. 

The Primary Key of volunteermatch is set to be the volunteers name, as we do not want any volunteers who have already gone through the process to be pushed through as a new volunteer. If they want to change job titles, it's a much quicker simpler process. 

This is a split table, on a share drive. I have the backend hidden in a boring sounding file elsewhere on the drive, and the front end where volunteer coordinators can get to it. 

The volunteers name is the one to one relationship that I have set to link all the tables together, as the volunteers name is the only information that stays the same. 

I want to make a report that takes the volunteers name from the volunteer table, if they were accepted or rejected from the interview table, and lists their references and if their references have passed from the reference table so that the members of my team who do the reference checks can easily print out all the volunteers who need reference checks, along with the information on who they need to call etc. 

But when I try to use the report Wizard to pull from the different tables, I get Application-Defined or Object-defined Error. 

I tried to look up what this error means, but all I could find was references to code. My table uses no VBA code. It's a pretty simple database, because I have taken all of 1 and 1/3 classes on access and 1/3 class on VBA (It was a general learn a little of three type of programs class, the other 1/3 was excel.) All the tied tables are just tied with the look up Wizard. 

I am unable to make anything a trusted thingy, because I do not have the permissions on my computer, though I have been thinking of contacting IT and seeing if they could do it for me. 

Also my end users suck and keep finding new and brilliant ways to break my database. :(

What can I do? Do I need to completely re-do my database? In English, what have I done wrong that makes this error and how can I prevent it in the future?

Thanks, 

Rose Thorn.

Answer 1

You should Compact your database when needed, and it's sort of like doing maintenance on the database.

First, make a copy of your database. You can do that by closing out of the database, and then use Windows File Explorer to locate the database file. Press Ctrl+C and Ctrl+V, and Windows will create a copy.

Now open the database back in Access, and click the Office button in the top left corner, then Manage. You should see the Compact option there. Click that, and let Access perform the compact.

Here's an article that explains a bit more about Compact: https://support.office.com/en-US/article/Compact-and-repair-a-database-6EE60F16-AED0-40AC-BF22-85FA9F4005B2

Answer 2

I get the the error when I try to add fields from any additional table that is not the original table I'm pulling off of, or if I try to add existing fields to a report, from tables other than the first table. I can generate a report if I stay in only one table. 

My office and windows is 2007, though we are supposed to be getting 2010 soon. 

What is meant by compacting my database?

(I took one class in access, and was using the database for tracking purposes on my own, and then other people saw it and I was asked to make it for everyone. But I don't know a lot more than just the basics...)

Answer 3

But when I try to use the report Wizard to pull from the different tables, I get Application-Defined or Object-defined Error.

Where do you get this error? When you start the Wizard, or at some point during your work with the wizard?

Some things that may help:

Be sure your Office and Windows installations are fully up to date

Compact your database (make a backup first, of course).

Answer 4

ok, I have changed the database so that the primary key is an autonumber, instead of the volunteers name. I am still getting the error. I will put in a message to IT to see if I can get the database set as a trusted center. 

My tables are as follows

Volunteermatch

Date entered (=Date())

(Autonumber-primarykey) ID

VolunteersName L/F (Text)

Positions (memo)

Submitter - Relationship to (Volunteermatch coordinators - coordinators name)

E-mail (hyperlink)

Volunteer Reason (lookup wizard, Reasons table - reasons)

Adult/Minor (look up wizard, fill in my own, entered text, single value)

Experience/qualification (memo)

Applied At - relationship to (Branches - Branch)

General notes (memo)

Accept Reject (yes/no)

Sent to branch (Date)

Volunteermatch coordinators table

Primary Key Auto number (ID)

Section (text)

Coordinator Name (text)

Coordinator e-mail (hyperlink)

Coordinator Number (text)

Supervisor (text)

Reference table

autonumber primary key ID

Volunteers name - relationship to volunteermatch (volunteers name l/f)

Reference 1 (text)

Reference 1 number (text)

Reference 1 e-mail (hyperlink)

reference 1 accept/reject (look up, write own, one only)

Reference 1 notes (memo)

Reference 2 (text)

Reference 2 number (text)

Reference 2 e-mail (hyperlink)

reference 2 accept/reject (look up, write own, one only)

Reference 2 notes (memo)

Background req? (look up, write own, one only)

Background sent to vol (date/time)

Background cleared (date)

Notes on Reference (memo)

Orientation Table

Autonumber primary key ID

Volunteers name - relationship to volunteermatch (volunteers name l/f)

Sent for orientation (date)

Attended orientation (look up wizard, write own, one value)

cleared to start (look up wizard, write own, one value) Default value = "no"

start e-mail sent (Date)

General notes (memo)

Interview table

autonumber primary key ID

Interviewer

Branch - relationship branch (Branch)

Volunteers name l/f - relationship volunteers name l/f

Branch accept reject lookup wizard (write own, one only)

Notes (memo)

Answer 5

The Primary Key of volunteermatch is set to be the volunteers name, as we do not want any volunteers who have already gone through the process to be pushed through as a new volunteer. If they want to change job titles, it's a much quicker simpler process. 

I am unable to make anything a trusted thingy, because I do not have the permissions on my computer, though I have been thinking of contacting IT and seeing if they could do it for me. 

Also my end users suck and keep finding new and brilliant ways to break my database. :(

First, people names are NOT good primary keys for at least three reasons:

1. They may not be unique. There are people with the same name
2. They can change. People can get married, divorced, not like their names, etc. 
3. Text fields don't perform as well as numerical fields in joins.

So yes you should redesign. Use an AutoNumber as the Primary Key (and corresponding Foreign Key) You can then use a combination of values to check to see if a volunteer has applied before.

You have to set the database folder as a Trusted location. If you don't have permissions to do this, get IT involved.

You will need to work at bulletproofing the database. This will almost certainly involve using VBA to limit what the users can type. 

Finally, one to one relationships are rare. Without knowing the exact data you are trying to capture its hard to advise whether your database is designed properly. But there is a good chance its not. Tell us more about it and we can advise further.