Heads up - Spurious "You cancelled" message

[Guest]

Execution of a DLookup function on a form produced this error message:
Runtime error 2001:
You cancelled the previous operation

HUH? I racked my brain over this, but finally executing the DLookup in the
immediate window of the debugger provided the answer: I had misspelled the
name of the field being looked up! How's that for informative run-time
messaging? It happens in both A2K and 2003.

 

[Dirk Goldgar]

Execution of a DLookup function on a form produced this error message:
Runtime error 2001:
You cancelled the previous operation

HUH? I racked my brain over this, but finally executing the DLookup
in the immediate window of the debugger provided the answer: I had
misspelled the name of the field being looked up! How's that for
informative run-time messaging? It happens in both A2K and 2003.

Access 2002, also. It's a pretty well-known behavior, but thanks for
posting the notice, as I don't think I've seen it in print (or pixels)
before. I don't know what the exact under-the-covers processing is
going on that produces that message when the query generated internally
by DLookup is not valid, but it would be nice to get a less misleading
message.

 

[Guest]

Actually, I did not test it in A2K - I meant 2002 & 2003.

 

[Dirk Goldgar]

Actually, I did not test it in A2K - I meant 2002 & 2003.

It's the same in A2K, as far as I know.

 

[Guest]

This is only a wild guess, but I think, perhaps, Access constructs a query
and passes it to Jet. Jet can't resolve it and does not execute it (it
cancels it) and send that error to Access which interprets it as a canceled
operation. Jet is much smater than Access.

 

[Dirk Goldgar]

This is only a wild guess, but I think, perhaps, Access constructs a
query and passes it to Jet. Jet can't resolve it and does not
execute it (it cancels it) and send that error to Access which
interprets it as a canceled operation.

That my guess, too. So between the two if us, it must be right.

Jet is much smater than Access.

In some ways. But Access can resolve form references in queries, which
Jet by itself can't do. So nyah, nyah, Jet.

 

[Guest]

We have to remember that Microsoft did not originally write Jet. They
purchased it from Fox. It was the engine for FoxPro. Microsoft took the
FoxPro engine and put it in Access. This may explain some of the strange
messages.

 

[Dirk Goldgar]

We have to remember that Microsoft did not originally write Jet. They
purchased it from Fox. It was the engine for FoxPro. Microsoft took
the FoxPro engine and put it in Access.

I don't think that's true. I have read that they purchased FoxPro to
get the Rushmore techhnology, but I don't think that was all of Jet.
However, I don't consider myself very knowledgeable on the history of
Jet.

 

[Guest]

I don't know where you saw this, but any kind of error
in a before update/ after update event will cause this problem.
So you can avoid some of these problems by having an explicit
exception handler with message box in every before/after
update event handler.

It's an indication of poor integration between the various
components (Application, VBA, and Jet). When there is
an error that causes an Application action to be cancelled,
the original exception object is lost, with the original error
message, error source, and error location.

If the message was correct, the error location wouldn't matter
as much. If the error location was correct, the message
wouldn't matter so much.

To be minimally useful, all they need is a better message
that says "Operation cancelled because of error". In my
experience, "You cancelled the previous operation" is worse
than unhelpful.

And having to code an explicit exception handler into every
event is no solution. Although that is an acceptable work around
for some of my applications, if I wanted to work in an environment
where I had to code everything, I'd be working in assembler,
not Access.

(david)

 

[Guest]

You may be correct, but my understanding was Rushmore was the FoxPro engine.
I was a Registered FoxPro Developer at the time and remember when Rushmore
was first introduced.

I think Microsoft bought Fox about 1990-91. At that time, we got all our
updates through Compuserve which was an expensive per minute service.
Microsoft announced a critical, required update for FoxPro. At 1200 baud, it
took over an hour. I later found out that all it did was change the Fox
logos to Microsoft logos.

 

[Guest]

Even if Rushmore is all of the SQL interpretation in Jet,
Jet also includes the user-level security, the ldb file, the
storage container, and the virtual locks - none of which
were implemented that way in FoxPro. Therefore, Jet
is not FoxPro. ~

(david)

 

[Guest]

I worked for Microsoft at the time FoxPro was acquired. We were beta-testing
Access V1 before that acquisition. So the Jet engine is is not derived from
FoxPro, although later versions of both contained some cross-pollinated
features.

 

[Guest]

Thanks for the info. I do know at that time, FoxPro had the best desktop
database engine available. Access was a very weak product that was not taken
very seriously. Don't start the flame, I really like what Access has become,
but of the desktop products available them, it was not a real contender.
DBase IV fell on it's face and died, Clipper had to have an add in marketed
as Sexpack (I did not make this name up) to come close to the indexing
capabilities of FoxPro.

The acquisition of Fox and the inclusion of Rushmore in Jet put Access on
the map. In addition, as with most DOS based software, FoxPro had a bit of a
bumpy transition to a Windows environment. Visual FoxPro is a pretty good
product, but I would much rather work in Access.

 

[Guest]

I never said it was all of it. I said it was the basis of it. At the time
FoxPro was acquired, Access was not that good a product. Improvments in
Access and the addtion of Rushmore made Access an excellent product.