I've used Access for a while, so I know that Access queries which use
VBA functions or custom functions cannot be evaluated from outside
Access. This was never a problem for me before, but it is a major
obstacle in my current project. I'd like to do a little research into
the issue and see if I can find an elegant workaround.

>From what I understand, VBA functions work in Access queries because

DAO uses something in Access called the "expression service". I'd be
grateful if someone could help answer a few questions about the
expression service:

1. What kind of an animal is the expression service? Is it an object
that can be referenced through the Access object model?

2. Is there a way to create an instance of the Access expression
service from outside of Access and hook up that instance to DAO?

3. Do other applications, like VB6 or Excel, have their own versions
of the expression service, and can those be used to support functions
in queries?


-TC

"Allen Browne" <AllenBrowne@SeeSig.Invalidwrote in message
news:46cd03c4$0$27795$5a62ac22@per-qv1-newsreader-01.iinet.net.au...

AFAIK, Access does not expose the ES

AFAIK it does, via the Eval function...

Problem is, this can only be called within the Access environment, and it's
not an object,so even automation won't help to make use of it externally. I
suppose you could call RunCode to execute it, but that's a little too
convoluted for my liking - however others may disagree...

"Allen Browne" <AllenBrowne@SeeSig.Invalidwrote in
news:46cd03c4$0$27795$5a62ac22@per-qv1-newsreader-01.iinet.net.au:

AFAIK, Access does not expose the ES. It is not part of the VBA
model. I don't think it's part of the DAO model. My (limited)
understanding is that it is part of Access itself, but not exposed
through the Access library in code.

Access has its own expression service and so does Jet, for the
functions supported in both Jet and VBA. I don't know the particular
relationship between them, but I expect they are very closely
related, with the Jet ES handing off to the Access ES anything it
doesn't understand.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

"Stuart McCall" <smccall@myunrealbox.comwrote in
news:fak5ls$5hb$1$8302bc10@news.demon.co.uk:

"Allen Browne" <AllenBrowne@SeeSig.Invalidwrote in message
news:46cd03c4$0$27795$5a62ac22@per-qv1-newsreader-01.iinet.net.au..
>

>
AFAIK it does, via the Eval function...
>
Problem is, this can only be called within the Access environment,
and it's not an object,so even automation won't help to make use
of it externally. I suppose you could call RunCode to execute it,
but that's a little too convoluted for my liking - however others
may disagree...

Huh? Eval is a member of the Access.Application object, as is almost
anything that you can call as a standalone command without any
prefixing object.

Take a look at the Object Browser -- it tells you exactly what
object these kinds of things hang off of (as it were).

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

"David W. Fenton" <XXXusenet@dfenton.com.invalidwrote in message
news:Xns9995796CCE367f99a49ed1d0c49c5bbb2@127.0.0. 1...

Eval is a member of the Access.Application object

Of course it is <slaps forehead>. Duh.

Thanks