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]

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?

[Scrooge McSam]

"You must spread some mojo around before giving it to Ghoulish Delight again"

[blueerica]

Whacking the monitor, unfortunately, didn't work.

I am going to give the relinking thing a try. However, we were actually trying to create a new table and relationship and getting that error (If I'm understanding the situation correctly, which I may not. I'm only just now learning the mapping thing). I am thinking, however, that there's something to be said for going the Linked Table Manager route.

As far as the helpfulness of IT, most over there don't know what to do when it comes to Microsoft Access. So yes, that has been considered. I've just got a grudge at the moment, because IT slaps me down when I request a three hole punch or a certain kind of marker that shows up on dark catalog paper for our review. They control everything. :(

And this didn't help... there are people who know it, but I've been told they're not available. (Which yes, I understand that there are other projects out there, it's not what I'm trying to say... it's just that marketing gets almost no support, and has been threatened to be cut for the company, though we've tripled the revenues for my company since the department began just a few years ago)

[Kevy Baby]

Whacking the monitor, unfortunately, didn't work.Percussive Maintenance was successful? Wow - this really is a serious problem!

[blueerica]

Okay, what I am seeing is that if I try to link up the database on a new table, it's still not working. Or at least that's what I think happened. I am going to be studying Access tonight from a book that looks like it's bigger than the Bible. So, um, wish me luck...

[BarTopDancer]

Godspeed

[Pirate Bill]

Can you post screen shots of the list of tables? And maybe a screen shot of the error?

[Gemini Cricket]

Have you tried whacking the monitor a few times?
No fair. That was going to be my suggestion.
:D

[blueerica]

Can you post screen shots of the list of tables? And maybe a screen shot of the error?

I will try to do it again tomorrow, if I can't discern more from the Access 2000 Bible. Just got out of retard-o conference calls and have to leave early.

[Kevy Baby]

Did you try jiggling the thingamajig and nudging the doohickey?

[LashStoat]

Dear BlueErica,

Before I even read Pirate Bill's post, I was going to suggest that the problem will definitely have been caused by changing the file locations during migration. The Linked Table Manager on the Tools Menu is the way to repair the file associations, but I think you said you still had trouble?

If so, is it possible that different versions (ie: restored from backups) have been mixed around, thus breaking the integrity of the system? Perhaps the file dates could help determine this. Are you able to run a Repair on the database(s)?

If you really, really get stuck, could you get the IT people to create a drive and folder structure that is identical to the original (ie: same drive letter and folder heirarchy), which will give you a stable starting point.

I hope this helps,

Love and hugs,

The Stoat XXX.