Editing fields in a linked table

[Fly Boy 5]

I have 3 tables linked together. Customer, Fillers & Service. All three are
one to many.

I'm trying to change the name of two or three fields in the Service table,
but it causes a pop up when I open the database. I tried to delete the field
with same results.

Any suggestions would be appreciated.

Fly Boy 5

 

[Jeff Boyce]

Perhaps there is a difference of definition.

In Access, a "linked" table isn't really in the file you open. Therefore,
you can't make changes to it.

Usually, in Access, when several tables are related to each other, you use a
"join" in a query to connect them.

Does this clarification help?

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[John W. Vinson]

I have 3 tables linked together. Customer, Fillers & Service. All three are
one to many.

I'm trying to change the name of two or three fields in the Service table,
but it causes a pop up when I open the database. I tried to delete the field
with same results.

Any suggestions would be appreciated.

Fly Boy 5

Open your database. Select Tools... Options... General.

UNCHECK the Track Name Autocorrect Information checkbox. This feature has
richly earned the nickname "Name Autocorrupt".

Compact and repair the database, and try again.

It might be necessary to create a new, empty database; uncheck Name
Autocorrect; and import all the objects from your current database.

 

[Fly Boy 5]

It was all ready unchecked.

Thanks,

Open your database. Select Tools... Options... General.

UNCHECK the Track Name Autocorrect Information checkbox. This feature has
richly earned the nickname "Name Autocorrupt".

Compact and repair the database, and try again.

It might be necessary to create a new, empty database; uncheck Name
Autocorrect; and import all the objects from your current database.

 

[Klatuu]

If you are trying to modify the structure of a linked table (changing a field
name qualifies), you cannot do it easily from the front end database. You
have to make the change in the database file (mdb, accdb) the table is in.

It can be done, but it takes a bit of code and is not advisable unless you
have a good reason. For example, I worked on an application where there were
about 500 different backend mdbs. The front end would use the one specified
by the user selecting a client. This was because they were all very large
with some well over a gig.

As you can imagine, if you make a structure change in this case, it is a lot
of manual work to open, modify, and save 500 mdbs. To solve this, I wrote a
small app that would use a "template" mdb where the changes had been made,
then programmatically open each mdb and make the changes.

 

[Jeff Boyce]

Dave

It sounds like you're describing a situation in which you allowed your
end-users to modify the db structure? If so, how did you maintain a
well-normalized structure, given that "normal" isn't all that normal, and
most folks don't ...?!

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[Fly Boy 5]

I have converted from 2003 to 2007. Would it be easier to delete the fields
and make new ones or just make new and leave the old ones alone?

Thanks for you help

 

[Fly Boy 5]

End users did not modify anything.

Thanks,

I have converted from 2003 to 2007. Would it be easier to delete the fields
and make new ones or just make new and leave the old ones alone?

Thanks for you help

 

[Klatuu]

Jeff,

Do you think I am as crazy as I look

No, it was not for users. I was the only one to use it. All 500 back ends
resided on our servers. Because of the volume of data for each client, we
separated the data by client/region. Then in the user app, when the would
choose a client/region to work on, the app would drop links to the current be
and it would relink to the one selected. One table had the path to each be.

To avoid a loooooooonnnnnggggg week end of modifying data structure, I would
rin the app that would modily all the bes. It took about 2 hours to run.

 

[Jeff Boyce]

My bad ... I thought you were giving users the 'key to the city' (local
reference, I'll tell you about it sometime...<g>)

Regards

Jeff Boyce
Microsoft Office/Access MVP

Jeff,

Do you think I am as crazy as I look

No, it was not for users. I was the only one to use it. All 500 back
ends
resided on our servers. Because of the volume of data for each client, we
separated the data by client/region. Then in the user app, when the would
choose a client/region to work on, the app would drop links to the current
be
and it would relink to the one selected. One table had the path to each
be.

To avoid a loooooooonnnnnggggg week end of modifying data structure, I
would
rin the app that would modily all the bes. It took about 2 hours to run.

 

[Jeff Boyce]

(... and here I'd been hoping that you'd come up with a magical way to
ensure R.I.!...)

Regards

Jeff

Jeff,

Do you think I am as crazy as I look

No, it was not for users. I was the only one to use it. All 500 back
ends
resided on our servers. Because of the volume of data for each client, we
separated the data by client/region. Then in the user app, when the would
choose a client/region to work on, the app would drop links to the current
be
and it would relink to the one selected. One table had the path to each
be.

To avoid a loooooooonnnnnggggg week end of modifying data structure, I
would
rin the app that would modily all the bes. It took about 2 hours to run.

 

[Klatuu]

LOL,
wish I had. I'd be rich and famous by now