Thanks, Kirk. > On Mar 6, 2018, at 10:24 AM, Kirk Brooks via 4D_Tech <[email protected]> > wrote: > > 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 < > [email protected]> 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. >> [email protected] >> >> >> >> >> ********************************************************************** >> 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:[email protected] >> ********************************************************************** > > > > > -- > 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:[email protected] > **********************************************************************
_________________________________________ Bob McKeever http://www.mswl.com <http://www.mswl.com/> McKeever's Software Wizardry Port Coquitlam, B.C. [email protected] ********************************************************************** 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:[email protected] **********************************************************************
