Prev: A2010. Can be accessed by phone?
Next: How do I determine if the FormHeader has focus in a continuous form ?
From: elg on 28 Jul 2010 08:52

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.
From: David W. Fenton on 28 Jul 2010 13:38
elg <envirocomp(a)ukonline.co.uk> wrote in
news:8e6ba9df-07d9-46d0-93b3-2840c03c0905(a)f6g2000yqa.googlegroups.com
:

> 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.

A couple of URLs would be helpful.

--
David W. Fenton http://www.dfenton.com/
contact via website only http://www.dfenton.com/DFA/
From: Tony Toews on 4 Aug 2010 19:53
On Wed, 28 Jul 2010 05:52:53 -0700 (PDT), elg
<envirocomp(a)ukonline.co.uk> wrote:

>
>Basically of you look thro' Access on Google you'll gather that nobody
>quite understands why error 1517 should arise. - I'm talking about

??? 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/
From: David W. Fenton on 5 Aug 2010 14:52
Tony Toews <ttoews(a)telusplanet.net> wrote in
news:8bvj56hkhei35nkn5fa73ffbhto21hc4et(a)4ax.com:

> On Wed, 28 Jul 2010 05:52:53 -0700 (PDT), elg
><envirocomp(a)ukonline.co.uk> wrote:
>
>>
>>Basically of you look thro' Access on Google you'll gather that
>>nobody quite understands why error 1517 should arise. - I'm
>>talking about
>
> ??? 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

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/
From: Tony Toews on 6 Aug 2010 16:25
On 5 Aug 2010 18:52:15 GMT, "David W. Fenton"
<NoEmail(a)SeeSignature.invalid> wrote:

>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.

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/
 |  Next  |  Last
Pages: 1 2
Prev: A2010. Can be accessed by phone?
Next: How do I determine if the FormHeader has focus in a continuous form ?