Robert, 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 C_POINTER($1) C_OBJECT($obj) $obj:=OB_New $obj:=OBJ_get_obj (<>appObject;"scoreData") $1->:=$obj 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 think. On Mon, Mar 5, 2018 at 8:00 PM, Robert McKeever via 4D_Tech < 4d_tech@lists.4d.com> 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 http://www.mswl.com < > http://www.mswl.com/> > McKeever's Software Wizardry > Port Coquitlam, B.C. > bobmckee...@mac.com > > > > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: https://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:4d_tech-unsubscr...@lists.4d.com > ********************************************************************** -- Kirk Brooks San Francisco, CA ======================= *We go vote - they go home* ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: https://lists.4d.com/mailman/options/4d_tech Unsub: mailto:4d_tech-unsubscr...@lists.4d.com **********************************************************************
