Microsoft JET, Access, frustration, and tears...

[blueerica]

Okay, so I haven't cried yet. I barely understand the problem, just that there is one. I haven't used Access in years, so this is hardly intuitive, so please bear with me on this question, and if you have any of your own, I will do my best to answer them.

Some time ago, my company put together service area maps that included sales zones, density, etc. I've begun working with the mapping (as some of the duties will be transferred to me), and a problem that had been noticed earlier came up once again.

Back in the day, which was a Wednesday, by the way, my co-worker built the maps and related files on his computer. Let's just say there are many maps. It eventually came time to get a different computer, a laptop with which he could take his work on the road. The files were 'copied' over by someone in IT, and so on and so forth. He hadn't worked on mapping immediately after getting the new computer, but when he needed to revisit his maps for updates... well... he got this error:

Microsoft Jet database engine could not find the object 'XYZ.dbf'. Make sure the object exists and that you spell its name and the path correctly.

He recognized this problem early on, but due to having items of higher importance on his plate, it's only being talked about now. We have (easily) come to the conclusion that something happens when it gets copied. Integrity is lost in the relationships, files missing, incorrect paths - are things we've considered.

Since the time it got transferred to his laptop, all of the mapping data, files, etc, got transferred to an external hard drive, in the hopes that we'd be able to move it back and forth as needed.

So, here are a few questions, or if someone has a solution or has experienced this, please feel free to ignore the questions and help me find a solution...

Are .ddf files normally found alongside normal access/jet files? How are they correct or incorrect?

".dat files need to be in correct directories" - what does that mean, and... uh... how might this apply?

Is there a solution to make copied files work/accessible?

We're considering deleting everything and starting essentially from scratch. If we decide to pursue this, is there a way to prevent this copied files issue from being a problem. We also figure that putting it on our marketing server could create issues, since it may come down to being the 'copy' from the backup file.

HALP.

Like I said, I barely understand what's wrong, but if anyone can understand what I really mean, it would be a great help.

[BarTopDancer]

Is the application that was used to create the files installed on the machine?

Is it the same version used?

Did you email the Halp desk?

Did you bribe IT?

[DreadPirateRoberts]

Do you have access to the source for this application? Is the .dbf copied to the same location on both machines?

[blueerica]

Will check on question number 1, but I think so, yes. Though maybe not.

Yes, same version used. Access 2000.

He has done so in the past.

They don't know how to help us, which is retarded. But that's more because certain people in our IT department (that don't have IT degrees, just 'gatekeepers') have a grudge against Marketing, even when we're making maps for salespeople to use to sell stuff and to grow our company, which helps the company pay their salaries.

So yeah, I'm sure someone could help us, but marketing is at the bottom of the priority list, so the few that would know are assigned elsewhere, if what I've seen thus far is correct.

I'm going to go get an IT degree now, so I can solve my own problems.

(sniffles)

[Scrooge McSam]

Because of the file extensions you mention, I'm assuming these are tables linked through ODBC.

Has anyone tried to re-establish the links?

The least little change in directory structure while moving from one computer to another would have broken them.

PS... Linked tables display with an arrow next to them in the main database window

[blueerica]

Oh, yes, the original machine was wiped, so we only have copies. It was the databases that were copied over, so I'm wondering what that actually means.

[BarTopDancer]

Originally Posted by blueerica

Will check on question number 1, but I think so, yes. Though maybe not.

If the application is not installed, that may be causing it. I'm not sure.

They don't know how to help us, which is retarded. But that's more because certain people in our IT department (that don't have IT degrees, just 'gatekeepers') have a grudge against Marketing, even when we're making maps for salespeople to use to sell stuff and to grow our company, which helps the company pay their salaries.

So yeah, I'm sure someone could help us, but marketing is at the bottom of the priority list, so the few that would know are assigned elsewhere, if what I've seen thus far is correct/

They may very well not know how to help you because they aren't familiar with the applications. Despite popular belief, IT people don't know everything about every application. I know I can't help my Marketing department with most of their applications because I don't have a clue how Photoshop or stuff out of Adobe Creative Suite works.

[Betty]

Get your boss to tell the IT person's boss to get over it and make it a priority?

[Pirate Bill]

I might be able to help, but I'll need more information.

I'm assuming these maps are tables in an Access database. Right?

Are any of the tables linked tables? Or are they all local? (Linked tables will have an arrow just to the left of the table icon.)

If the table that can't be found is a linked table and you moved everything to another computer then you may get this error if the path to the new location isn't exactly the same. Access doesn't use relative paths to linked tables. It's all absolulte. So if the old table was located in C:\documents\access\db1.mdb then you move the database to C:\documents\access\new\db1.mdb, you get the error you posted.

In this case you have to relink the table. You do this by opening Tools -> Database Utilities -> Linked table manager. Select the table you want to relink, select Always prompt for new location and click on OK. You'll be given a dialog box to find the new table.

The table must also have the exact same name or the link will fail. (You can rename a linked table, but not the local table.) If the name of the table changed you'll just have to change it back or link it in again and delete the old linked table.

If you mouse over a linked table you can see the path and table name (if the linked table has a different name than the original) Access is expecting to find it.

[Ghoulish Delight]

Have you tried whacking the monitor a few times?