John's suggestion about a worker process is a good one. It sounds like
you're just starting into this area so I'll throw out out a few things that
aren't readily apparent.

I use Execute on server (EOS) methods a lot. When a method is EOS it runs
on the server but in the 'twin' process of the one on the client. Let's say
I've opened an order in a new process named 'order_1234'. I have the actual
record open and locked on my client machine. That is, it's locked by the
client process.

Now I call a method to lookup some stuff. Since it's a big lookup (or like
me you are running over TCP/IP between the server and client) I use an EOS
method. That method runs on the server in the process named 'order_1234'
but the server side of the process, the 'twin', doesn't share the context
of the client side. So there is no current order record on the server yet,
for example. And if I try to load the order record on the server it will be
locked because it's already open on the client side.

This can be useful. Let's say I've got some Order Lines in a related table.
On the client side I probably have a current selection of them in a listbox
or subform. On the server side I could do a search on that table, create a
completely different current selection yet not disrupt the current
selection on the client.

This can also create problems. If I forget to explicitly set the server
side process to READ ONLY(*) before using it then I can lock a record in
that process. The LOCKED ATTRIBUTE will only tell me it's locked by the
'order_1234' process - not WHICH VERSION of the process has it locked. That
one stumped me for a while in one case. I just could not find where a
record in a table was getting locked especially since I called READ ONLY(*)
when the process started. Eventually I realized the situation was resulting
from an EOS method that did a query and left the selection with the record
locked. Grrr. So now the method that runs when I create a new method calls
an little EOS method which sets all tables to READ ONLY.

The other type of server side process is what we call a stored method. This
is initiated from the client by Execute on server or by simply creating a
new process on the server itself. When you do this these processes exist
only on the server and are conceptually similar to a Worker process.
Workers have the cool feature of their own messaging system however. But
simple server side processes are useful as well.

I use them for doing things like aggregating information that may be
displayed on various client side forms or dashboards. I just finished work
on a 'sales scoreboard' feature. A stored method periodically (every 5
minutes) builds a set of summary arrays of sales data folks are interested
in. I stuff them into an IP c-obj on the server. I use this same c-obj for
a number of operations like this.

The cool benefit of server side IP vars, and especially c-objects in my
view, is that any client can access that data with a simple EOS function.
This DOES NOT use Get Process Variable which can be problematic. You don't
need to. Here's the method that gets the sales data:

  //  Score_get_data **EOS**
  // Written by: Kirk as Designer, Created: 03/06/18, 08:50:48
  // ------------------
  // Method: Score_get_data (ptr)
  // $1 is ptr to c-obj
  // Purpose: get the data object from the server

$obj:=OBJ_get_obj (<>appObject;"scoreData")

I add the **EOS**  to the headers of methods to make it easy to remember
which ones are. Otherwise you have to look at the properties.

This is called from the form on the client. I don't need to worry about
locking the IP var because I'm only reading it. You can also use this to
write to the server side variable but this gets more complicated if you
actually use it. So I stick to reading from the server side only.

I pass a pointer to a local object var. This is a pretty handy way to let
your server manage this sort of operation without having to add the
overhead of a messaging table where the server process writes data to a
table and the client side reads from the table. I did it that way before
but this is just easier.

Just some ideas. The best thing to do is start up a server and just play
with it. This all gets a lot clearer when you can actually see it work, I

On Mon, Mar 5, 2018 at 8:00 PM, Robert McKeever via 4D_Tech <> wrote:

> I have two processes, one foreground, the other background (runs
> continually with appropriate pause/resume). There are a few dialogs that
> exist in the background process that can be eliminated. Since it does a lot
> of information gathering before creating/deleting a record and updating
> another, I’d like to move it so it executes on the server. It see that it
> creates a new process on the server.
> 1. Is that a unique process for each user, or only one process for all
> users?
> 2. Are the local variables in use on the ‘client’ the save as when you use
> ‘Execute on Server’? e.g., if I start the process on the server, does it
> share variables with the client or must they be exchanged via a record in a
> table?
> _________________________________________
> Bob McKeever             <
> McKeever's Software Wizardry
> Port Coquitlam, B.C.
> **********************************************************************
> 4D Internet Users Group (4D iNUG)
> FAQ:
> Archive:
> Options:
> Unsub:
> **********************************************************************

Kirk Brooks
San Francisco, CA

*We go vote - they go home*
4D Internet Users Group (4D iNUG)

Reply via email to