Larry,

It has the considerable dual advantages of being both simple and
operable on just about any platform from'95 to XP, from Office '97 to
C#, etc. When it fails, it is pretty obvious what the problem is.
Further, it provides COMPLETE isolation between applications - well
almost complete as my problem illustrates.

Note in passing that I am also having problems with COM for the very
same reasons! Dragon NaturallySpeaking uses COM for its internal
communication, and RPC calls also have similar completion times
associated with them, and sometimes THEY are timing out, which causes
errors in its speech recognition! Unfortunately, the builders of this
product protected it from having its priority adjusted, so I can't just
jack it up when I know that CPU cycles are getting tight. Unfortunately,
I can't even see these problems from my application.

This is a "conversational" system, which means that both speech
recognition and speech synthesis are running, sometimes at the SAME
TIME, e.g. you pause while speaking and the computer starts talking back
at you WHILE it continues to figure out what you just said and how to
fully respond to it. Such systems are and will probably always be
overloaded, because if they aren't overloaded, then someone will just
crank up the amount of analysis being done until they are overloaded.
This is now often done automatically in some AI software. By their
nature, overloaded systems always have unpredictable delays in their
internal communications, especially when priorities are being jerked
around every second or two, e.g. shifting priority from recognition to
synthesis as recognition proceeds while the computer is speaking. This
is a little like "tournament mode" in some chess playing programs - they
are ALWAYS busy, even when it is your turn. Hence, whatever I do must
NOT involve any short fuses, be they DDE or COM in nature.

To illustrate, Dragon NaturallySpeaking runs at about the same speed on
a 2GHz system as it does on a 300MHz system!!! Why? It plans to keep up
with real time, and adjusts its depth of analysis accordingly. Hence, my
competition for the CPU probably won't slow it down, but it will degrade
its speech recognition accuracy.

Some people have suggested that this application would be trivial on a
3-computer client mini-network - one to speak, one to listen, and one to
think. Unfortunately, as a product this would be a horrible flop, even
if everyone who DID have their own little 3-computer desktop bought it!

I can see LOTS of alternatives. I was just hoping for some way to make
what I have work until later when the Access routine on the other end is
converted to VB, whereupon I will have access to the LinkTimeout
controls I need to make this problem go away.

This may indeed be the exception. This is a distributed AI application
where inquiries require some part of a minute of CPU time, even with
compiled code. This would crush a server if dumped on it. It didn't
start out so heavy on the CPU and was OK in Access until people found so
many new and CPU intensive things that just had to be in there. Creeping
requirements - you probably already know about those.

This isn't going to get completely out of Access - just the pieces that
really need the speed, which we wish to distribute onto computers w/o
Access, and where we wish to hide some of the whiz-bang technology. The
DB maintenance will still all remain in Access.

The simplistic approach appears to just abandon DDEExecute and the
built-in completion handshake (with its 5 second timer), and send the
work to be done over and periodically check a control via DDE to see if
it is done yet. Just a few lines of code to change from what I now have
- but ugly, and a possible problem for Dragon NaturallySpeaking as
timers have a nasty habit of messing up both speech recognition and
speech synthesis. I just HATE stuttering computers!

Thanks for your thoughts and offer of help.

Steve Richfie1d
======================