The microsoft jet database could not find the object...

[SuzyQ]

I have been working on splitting my database and dealing with corruption for
the past month. I've done everything needed to fix the corruption and think
it is resolved. However I got this message when attempting to link to an
arcMap database (it's a .dbf file, probably dBase but not sure of the
version, however I've linked to it before using the dBase IV option in Access
2000. I thought I was still dealing with corruption, but then I created a
new blank database and with nothing esle in it tried to link the table with
the same result. Since it can't be corruption in a new database (or could
it?), what could be causing my inability to link .dbf tables in Access 2000?

 

[SuzyQ]

I forgot to put the complete message that I received in my post. Here it is

"The Microsoft Jet Database could not find the object
"waterDiversionPoints.dbf" Make sure the object exists and that you spell
its name and path correctly"

This message occured while selecting the file from the dialog box, so the
path and name are definately spelled correctly. I could understand if there
was corruption in the database that I might get this error, however, I also
attempted to link to this table from a new, blank database and still got the
message. Why?

 

[Jerry Whittle]

Are you still using Access 2000?
Have you done something like a reinstall of Access in an attempt to fix the
corruption issues?
If you try a manual import from that dbf file, does .dbf show up in the list
of items to import or do you have to manually select the files?

 

[SuzyQ]

Yes, still using Access 2000. ugh.

Yes, reinstalled Assess in an attempt to fix the corruption issues.

Not sure what you mean by "do a manual import" from that .dbf, I use the
file menu -> Get external data -> Link tables... and select the table from
the dialog box that opens.

- additionally, I have several .dbf's that I need to link and I get the same
message with all of them (different filename of course, but same message)

 

[John W. Vinson]

I forgot to put the complete message that I received in my post. Here it is

"The Microsoft Jet Database could not find the object
"waterDiversionPoints.dbf" Make sure the object exists and that you spell
its name and path correctly"

I am pretty sure you need the complete path to the file, e.g.

"C:\My Documents\Waterdata\waterDiversionPoints.dbf"

rather than just the filename. You may also need a reference to the .dbx index
file, if I recall aright.

 

[SuzyQ]

I'm selecting the file from the dialog that opens when you select file->get
external data->link tables... Access should know the path and file name
because it is being navigated to and selected.

 

[Gigamite]

I forgot to put the complete message that I received in my post. Here it is

"The Microsoft Jet Database could not find the object
"waterDiversionPoints.dbf" Make sure the object exists and that you spell
its name and path correctly"

Rename the file to H20DivPt.dbf and it should work. You can't use more
than 8 chars for the dbf file name.

 

[John W. Vinson]

Rename the file to H20DivPt.dbf and it should work. You can't use more
than 8 chars for the dbf file name.

D'OH!!!

Thanks, Gigamite. I knew that once but had forgotten it.

 

[SuzyQ]

I've had it connected before. I can't rename it, it is used in a different
program. I will copy it and rename it as a test to see if this works, but I
have another database that it is already linked to. I have to link it to
this database because I've been in the process of splitting several databases
and combining all the forms/reports into ONE front end application. This is
one of the tables that was connected to one of the backend data sources when
it was a single file (before the split)

 

[SuzyQ]

Don't know why you think that. I have it connected in another database as
WaterDiversionPoints.dbf However, I did copy/rename it to H20DivPts.dbf and
it still gives me the same message, so this is not the issue.

 

[SuzyQ]

Actually, those links are not working now either. They are there though, and
I have used them. So at some time I was able to link to these tables because
I have reports and queries that access them and were working.

At any rate, even renaming to a short name did not resolve the issue.

 

[Gigamite]

Don't know why you think that. I have it connected in another database as
WaterDiversionPoints.dbf However, I did copy/rename it to H20DivPts.dbf and
it still gives me the same message, so this is not the issue.

It's one of the issues. I think your database has more than 1 issue to
get through.

If you can't rename the file, type the Windows short name for the file
when you're linking the table. The short name is probably WaterD~1.dbf
but to be sure, open a command prompt, go to the directory where the
file is stored, and type

dir water* /x

and press the Return key. The 5th column shows the Windows short file
name, the 6th column shows the long file name, WaterDiversionPoints.dbf.
Ignore any other file names in the list.

 

[Gigamite]

Don't know why you think that. I have it connected in another database as
WaterDiversionPoints.dbf However, I did copy/rename it to H20DivPts.dbf and
it still gives me the same message, so this is not the issue.

Found your problem. Your file name is 9 chars, not 8. You added an
extra "s" to the name. Copy and paste the file name I posted (or any
other 8 char name), and it should work.

 

[SuzyQ]

I'll try tomorrow. But I still don't understand why I have a link to the
name as is and it was working in a different database.

 

[SuzyQ]

Can I connect it from the menu that way, or do I need to write code to
connect to it with a short name.

 

[Gigamite]

I'll try tomorrow. But I still don't understand why I have a link to the
name as is and it was working in a different database.

It's probably using the Windows short file name, not the long file name.

 

[Gigamite]

Can I connect it from the menu that way, or do I need to write code to
connect to it with a short name.

You can use both. But you need to type the 8 char short file name when
you link the table with the linked table manager.

Example:

WaterD~1.dbf

 

[SuzyQ]

Thanks for you help. I know I was being stubborn, but that's just because I
know what I saw. It did work by connecting with the short name however, when
I originally connected it in the original back end, it connected using the
long name. I still have it connected in another database and when I look at
the linked table manager, it shows the long name. I'd really like to know
why. I must have had some compatibility patch or something installed that
when I uninstalled/reinstalled access, I lost my ability to connect to long
names. I don't know how else I could have connected to it before.

 

[Gigamite]

however, when
I originally connected it in the original back end, it connected using the
long name. I still have it connected in another database and when I look at
the linked table manager, it shows the long name.

I don't know of any version of Access that allows linking a dbf file of
more than 8 chars through the GUI. But lots of things that are
impossible through the GUI can be done with VBA code. I leave it to you
to test the theory that a link can be made to a dbf file with a long
file name with VBA.

I must have had some compatibility patch or something installed that
when I uninstalled/reinstalled access, I lost my ability to connect to long
names. I don't know how else I could have connected to it before.

There's no compatibility patch that allows linking dbf files with long
file names through the GUI. I don't know if Microsoft still does this,
but back in the 90s they built custom versions of Office for companies
that ordered huge numbers of licenses (50K if I recall). The custom
versions had a few features the retail and MSDN versions didn't have.
But if you had a custom version of A2K at your company, you'd know it.

 

[SuzyQ]

I guess it will remain a mystery. I would be the only one who would have
linked the file and although I have done it through code before, I can't find
anywhere in my code where I did it this time. I may test the theory, but for
now, it's working. Thanks for all your help.