Basically of you look thro' Access on Google you'll gather that nobody
quite understands why error 1517 should arise. - I'm talking about
Access 2000 only here.
Error messages in books/manuals tend to run from 3 to 94, 321 to 746
(with gaps) and then 3000 to 3673. I've printed my own list which is 3
to 95, 280 to 298, 2000 to 3428, 7750 to 7591 (all inclusive) I've
never seen any in the 900 to 1999 range. I'm of the opinion that 1517
is related to odd or intermittent hardware/network errors. Probably
related to timing, meaning the program sends a message to the server
and as it doesn't receive the message back in time either gives the
1517 error, shows incorrect data or rarely, places a corruption in the
database that is not removed with a pack. It will usually throw the
1517 error and also place #error into a field for no clear reason. In
the final analysis I think that the problem is with the customer's
hardware but it is difficult to prove (particularly if they don't
listen/understand). I don’t think that it’s an Access2000 software
problem. If you move the application and data to (say) your laptop or
a sound PC these errors won’t appear when you complete the same
operations.

elg <envirocomp (AT) ukonline (DOT) co.uk> wrote in
news:8e6ba9df-07d9-46d0-93b3-2840c03c0905 (AT) f6g2000yqa (DOT) googlegroups.com
:

A couple of URLs would be helpful.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

On Wed, 28 Jul 2010 05:52:53 -0700 (PDT), elg
<envirocomp (AT) ukonline (DOT) co.uk> wrote:

??? I've noticed this problem several times when I've added a
foreign key to a table in the backend which was inserted into the
middle of a table. Everything would work fine for days or weeks until
the backend was compacted. Then the FE would puke with the -1517 error
whenever that particular table was accessed. But deleting the link
and recreating the link or compacting the FE made it work again.

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 convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

Tony Toews <ttoews (AT) telusplanet (DOT) net> wrote in
news:8bvj56hkhei35nkn5fa73ffbhto21hc4et (AT) 4ax (DOT) com:

Your quote from MichKa explains it quite clearly: there's metadata
stored in the linked table definition that has been obsoleted by
your change to the back end table. A compact obviously updates the
metadata implicated in this particular problem, and it seems to me
should be a rather obvious thing to do when you've changed the
structure of your tables.

I would almost never encounter this error because I compact front
ends so often during development.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/

On 5 Aug 2010 18:52:15 GMT, "David W. Fenton"
<NoEmail (AT) SeeSignature (DOT) invalid> wrote:

But you and I know that there is metadata being stored in the FE. If
you don't then it's not intuitive that you would need to compact the
FE if you change the BE. More mportantly this error occurs when you
insert a field into the middle of a table in the BE. Not when you
add a field at the end of a table.

Also this error would crop up days, weeks or months later when the BE
is compacted. So the cause and effect is not at all obvious.

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 convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/

Tony Toews wrote:

And your experience with this issue saved my sanity. I
always make table design changes using code (DDL and/or DAO)
so I have a canned script to run on copies of test back ends
and when installing a new version for a client. Since I
compact the FE frequently during development, I never
noticed the issue until on site installation. My quick
regression test after installing worked great, except for
one form that generated that mysterious error. While
scratching my head, I did a few housekeeping actions,
including Compact. Then when I went to dig into the form
with the error, there was no problem to solve. I went home
and immediately posted the weird happenings and you
responded with an explanation that the Compact I had
performed was the solution. It was a great relief to
realize that my only problem was testing before compacting.
For sure, I won't do that again.

Thanks again Tony

--
Marsh

Tony Toews <ttoews (AT) telusplanet (DOT) net> wrote in
news:8pro56p6dp6se7r1m4vdqv3vhrtq3kt8j7 (AT) 4ax (DOT) com:

I still just can't quite see how this kind of thing could cause a
problem in production use. If you add a field to a table, surely
you're pushing out a new front end simultaneously that *uses* that
new field? If so, not problem, so I just can't quite see how it
would be an issue for anybody but the developer, and I'd think any
developer who's been at it for a couple of months would already have
developed the instincts to do a compact/repair after any crash of
the front end.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/