Hello again, John, and thanks again for the reply.

>your problem is in the fact that VFP is single thread. The backround process is not
>really in the backround. All other processing stops while it is running.

Single threaded? No el forkola of a child proc? No asynchronous service queues
and calls. BLAH!!!! Just pickin' :^). There is an old addage: "You get what you
pay for." :^)

>The reason for your listboxes, etc. to lose their contents is because the table
>they are referencing is no longer avalable. I guess your update process is
>closing it or starting a private data sesson.

The previous database-synchronization code was being called by a command
button (click event) that end users have access to, and it works, but they
complained that they weren't seeing the listbox updates when another user
modified a record and such. So, to remedy this problem, I decided to set
a timer event that updates the database every 30 seconds.

Calling the database_sync() routine on a timer kinda' broke the previous
code,though, because the previous programmer wrote the code to be event
driven on click and various other user-initiated events. Anywho, I wound
up have to set a flag -- SPAGHETTI CODE KLUDGE ALERT! :^) -- when certain
situations arose to aleave myself of these problems. Well, it beats the
heck outta' rewriting all that code. Remember: this is production code
that's currently in use in the field, and the fix has to be done rather
quickly.

_VERY FORTUNATELY_ :^), all new apps we write will be written using PHP and
MySQL -- HOT DAMN!! :^) -- and they'll all be web based. OTOH, we'll still
be updating these VFP apps, from time to time.


>There is a simple fix for all of this. Create a seprate .EXE with one form
>with the timer that runs your update. That is the only way to fix your
>problem and it works great. That app should only need to be run on one PC
>if that pc can access the data on all the others. Note: Be sure the app
>closes all tables each time the process finishes.

Kewl. I'll try this and see how it works, although my "bandaid approach"
seems to be working. I can't really tell that the update is taking place,
although the mouse pointer changes from the default pointer to the hourglass
for only a split second. The single-threaded update is still happening, though,
but I'm hoping they won't really notice. That being said, the app is still
very usable. Should they complain or should the database become loaded down
with data, though, I'll go your route the entire way, John.

>If the app must run on each pc, which I STRONGLY recommend against, you can
>start it with the RUN xxx.exe /N command.

This app is used for dispatching, and we're providing this service for
multiple companies; thus, we require mulitiple data-entry clerks using
multiple computers. We have to use multiple computers, as they allow
us the ability to keep up with the supply and demand in a timely
fashion. I understand what you're saying here, John, but lets just say
that we're in a "damned if we do, and we're damned if we don't" situation
here :^).

Randall