Error 1517

  • Thread starter Thread starter Robert_DubYa
  • Start date Start date
R

Robert_DubYa

I have received this error 3 times in the last 24 hours. I can get the DB up
and going by compacting and repairing the backend DB, but within 2 hours it
appears again. I would like to know what could be causing this to happen.
The DB has been very stable and going for almost 2 years.

About this DB:

Using office 2003
is a backend DB with mulitiple front ends
it is located on a network share
no changes have been made to the db for many months
it appears that some clients (front end DB users) can still enter data while
others
get the 1517 error
Has been stable (till now) for about 2 years (creation)
Back End DB only 65796k
Problem disappears after BE compact but will reappear

If anyone knows why this continues to happen (or has theory) PLEASE reply.

Thanks to all who answer on this message board. You have all been great
mentors!
 
This error will occur if you change the design of a table, but don't
follow through with a compact (I know you said you compacted the BE,
but...). If your database is split, it is a good idea to compact the
backend after a design change, and also refresh the links in the
frontend and compact it.

I would follow through with a refresh of the links in each of the
frontends (you might want to consider deleting the links and recreating
them even).

Joan Wild
 
Joan Wild said:
This error will occur if you change the design of a table, but don't
follow through with a compact (I know you said you compacted the BE,
but...).
Click to expand...

Actually this error occurs when you insert a foreign key field into
the middle of a table. But it doesn't appear in the front end until
you've compacted the backend. So this problem might not appear for
weeks.

And yes to fix it you need to either relink the tables in the FE or
compact the FE.

Reserved Error (-1517) in Microsoft Access
http://www.granite.ab.ca/access/reservederror1517.htm

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
 
Tony said:
Actually this error occurs when you insert a foreign key field into
the middle of a table.
Click to expand...

Which is a change in the design, no? I have also experienced it with
*any* field, and not in the middle.
 
Joan Wild said:
Which is a change in the design, no? I have also experienced it with
*any* field, and not in the middle.
Click to expand...

Yeah, I was thinking later that this could occur with any field not
just a foreign key. But I don't think it ever happens when you add a
field to the end of the table list. At least that's been my
experience.

What is really happening, in my opinion, is that even though you add
the field to the middle of the list of fields on the table and it
appears to be in the middle of the table when you look at the table in
design view the field is actually still at the end of the field list
in the table. There's a property for table fields called Ordinal
Position or something like that.

So your Access FEs happily used that field and put some data in the
linked table cache in the FE. Now days or weeks later you compact
the backend. Compacting the BE actually moves that field into the
middle of the table. But now the cached data in the FE is wrong and
Access gives the -1517 error.

Which relinking the tables in the FE or compacting the FE fixes.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
 
What is really happening, in my opinion, is that even though you
add the field to the middle of the list of fields on the table and
it appears to be in the middle of the table when you look at the
table in design view the field is actually still at the end of the
field list in the table. There's a property for table fields
called Ordinal Position or something like that.

So your Access FEs happily used that field and put some data in
the linked table cache in the FE. Now days or weeks later you
compact the backend. Compacting the BE actually moves that field
into the middle of the table. But now the cached data in the FE
is wrong and Access gives the -1517 error.

Which relinking the tables in the FE or compacting the FE fixes.
Click to expand...

I just can't see how I've never encountered this. I know perfectly
well that metadata isn't all updated when your refresh links, but
since I never delete and recreate my links, you'd think I would have
encountered this somewhere along the line. I do tend, as a matter of
course, to compact a back end after altering its structure, but
that's more a matter of "well, I'm here in the back end with
exclusive access to it so I might as well take advantage of that by
compacting it" than it is of thinking I need to compact because I've
introduced a design change.

It's different with replicated databases, where it's crucial to do
TWO compacts after any design change in the Design Master before
propagating the design changes to the other replicas, so in that
case I do the double compact precisely because I know it can cause
unnecessary data to be propagated in a synch if you don't do it
twice.

I wonder if there's any relationship at all between the two
scenarios?
 
David W. Fenton said:
I just can't see how I've never encountered this. I know perfectly
well that metadata isn't all updated when your refresh links, but
since I never delete and recreate my links, you'd think I would have
encountered this somewhere along the line. I do tend, as a matter of
course, to compact a back end after altering its structure, but
that's more a matter of "well, I'm here in the back end with
exclusive access to it so I might as well take advantage of that by
compacting it" than it is of thinking I need to compact because I've
introduced a design change.
Click to expand...
I wonder if there's any relationship at all between the two
scenarios?
Click to expand...

No idea.

If you always add your fields to the end of a table list or (always
compact the back end and (relink the tables or compact the FE
immediately)) then you shouldn't have this problem.

Now when I think about this I'm not quite so sure that compacting the
FE solves this problem. I think it does but I can't exactly recall
that exact situation.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
 
No idea.

If you always add your fields to the end of a table list or
(always compact the back end and (relink the tables or compact the
FE immediately)) then you shouldn't have this problem.
Click to expand...

I absolutely do *not* put all my new fields at the end of the table
-- I put them logically where they belong, i.e., next to related
fields. That's almost always in the middle of the table somewhere,
except for metadata fields.
Now when I think about this I'm not quite so sure that compacting
the FE solves this problem. I think it does but I can't exactly
recall that exact situation.
Click to expand...

I'm glad I've missed out on this one, but the description of it
makes it sound like I should encounter it on a regular basis.

I'm thinking of my two currently most active development projects,
and in both cases, the users get a new front end immediately after
the addition of new fields, and those are always newly relinked
(refreshed .Connect property, not deleted and recreated). So maybe
that scenario avoids most of the cases where it's a problem.
 
David W. Fenton said:
I'm thinking of my two currently most active development projects,
and in both cases, the users get a new front end immediately after
the addition of new fields, and those are always newly relinked
(refreshed .Connect property, not deleted and recreated). So maybe
that scenario avoids most of the cases where it's a problem.
Click to expand...

Yup, relinking fixes it. And if you were working on the FE on your
system, updated your BE then updated the clients BE and then gave them
a new FE which was then relinked you'd never see it. But if you
gave them the new FE which was then relinked and then updated the
tables in the BE you could see this problem.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a free, convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/
Granite Fleet Manager http://www.granitefleet.com/
 
Yup, relinking fixes it. And if you were working on the FE on
your system, updated your BE then updated the clients BE and then
gave them a new FE which was then relinked you'd never see it.
But if you gave them the new FE which was then relinked and then
updated the tables in the BE you could see this problem.
Click to expand...

Ah. I'd never do it in that order, since that would cause errors
(because of the missing fields).
 
Back
Top