Timeout while DDE linking to a VB application.

[Steve Richfie1d]

Now that it finally works, I'm in the process of converting my large
rapid-prototyped Access app into production VB, one DDE-linked piece at
a time. One piece now already in VB takes ~2 seconds to run all by
itself, but when I start running other gigantic resource hogs like
Dragon NaturallySpeaking and SAPI at the same time, its execution time
goes WAY up - past the 5 seconds needed to time out a DDE link, so I get
an Error 286 DDE LinkTimeout error from a DDEExecute statement in the
remaining unconverted Access code.

There are plenty of postings about related problems, all saying to
adjust the LinkTimeout property. Unfortunately, there doesn't seem to be
a LinkTimeout property in the Access 97 that I am using.

Is there some way past this problem that hopefully doesn't require
complete reconceptualization of the interfaces?

Thanks in advance for your help.

Steve Richfie1d

[Larry Linson]

DDE, as far as I know, has only been kept around to maintain compatibility
with past efforts, and has had problems in the last few releases. It's not
something I've ever had need to use, even when it was "current technology",
though... COM automation replaced DDE in the development arsenal, and might
be a better choice for communication.

Without a good deal more information, I wouldn't be able to offer
suggestions for alternatives. Yours may be an exception, but I have rarely
seen an Access database application that would benefit from conversion to
VB, in a client-server environment. I have seen quite a few that appeared to
be Access written as though it were VB, and which could stand extensive
redevelopment to use Access to full advantage.

Perhaps with some clarification, someone might be able to suggest an
approach that would work for you.

Larry Linson
Microsoft Access MVP

"Steve Richfie1d" <St***@NOSPAM.smart-life.net> wrote in message
news:41*************@individual.net...

Now that it finally works, I'm in the process of converting my large
rapid-prototyped Access app into production VB, one DDE-linked piece at a
time. One piece now already in VB takes ~2 seconds to run all by itself,
but when I start running other gigantic resource hogs like Dragon
NaturallySpeaking and SAPI at the same time, its execution time goes WAY
up - past the 5 seconds needed to time out a DDE link, so I get an Error
286 DDE LinkTimeout error from a DDEExecute statement in the remaining
unconverted Access code.

There are plenty of postings about related problems, all saying to adjust
the LinkTimeout property. Unfortunately, there doesn't seem to be a
LinkTimeout property in the Access 97 that I am using.

Is there some way past this problem that hopefully doesn't require
complete reconceptualization of the interfaces?

Thanks in advance for your help.

Steve Richfie1d

[Steve Richfie1d]

Larry,

DDE, as far as I know, has only been kept around to maintain compatibility
with past efforts, and has had problems in the last few releases. It's not
something I've ever had need to use, even when it was "current technology",
though... COM automation replaced DDE in the development arsenal, and might
be a better choice for communication.
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!
Without a good deal more information, I wouldn't be able to offer
suggestions for alternatives.
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.
Yours may be an exception, but I have rarely
seen an Access database application that would benefit from conversion to
VB, in a client-server environment.
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.
I have seen quite a few that appeared to
be Access written as though it were VB, and which could stand extensive
redevelopment to use Access to full advantage.
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.
Perhaps with some clarification, someone might be able to suggest an
approach that would work for you.
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
====================== "Steve Richfie1d" <St***@NOSPAM.smart-life.net> wrote in message
news:41*************@individual.net...

Now that it finally works, I'm in the process of converting my large
rapid-prototyped Access app into production VB, one DDE-linked piece at a
time. One piece now already in VB takes ~2 seconds to run all by itself,
but when I start running other gigantic resource hogs like Dragon
NaturallySpeaking and SAPI at the same time, its execution time goes WAY
up - past the 5 seconds needed to time out a DDE link, so I get an Error
286 DDE LinkTimeout error from a DDEExecute statement in the remaining
unconverted Access code.

There are plenty of postings about related problems, all saying to adjust
the LinkTimeout property. Unfortunately, there doesn't seem to be a
LinkTimeout property in the Access 97 that I am using.

Is there some way past this problem that hopefully doesn't require
complete reconceptualization of the interfaces?

Thanks in advance for your help.

Steve Richfie1d

[David W. Fenton]

Steve Richfie1d <St***@NOSPAM.smart-life.net> wrote in
news:41*************@individual.net:

Larry,

DDE, as far as I know, has only been kept around to maintain
compatibility with past efforts, and has had problems in the last
few releases. It's not something I've ever had need to use, even
when it was "current technology", though... COM automation
replaced DDE in the development arsenal, and might be a better
choice for communication.

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.

I would basically say that if you're using DDE to get *data* out of
an MDB, then it's a mistake. If you're using DDE to automate Access,
then it may or may not be a mistake (I'd consider it a mistake, but
in some contexts, it may work better than COM automation).

Again, if Access is only used as a data store, and you're using DDE
to get at the data, then you're fundamentally mis-using the
technologies, in my opinion, because you're using full-fledged
Access simply to load Jet, and you don't need *any* of Access to use
Jet and Jet data. ODBC or ADO would be vastly preferable (as well as
substantiall more efficient, and not requiring the installation of
Access to work) if all you need is the data.

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