Chuck, Always an option. But managing IP arrays require local semaphores to manage read/write. On a local machine that's not too bad but on a busy server it could get to be a noticeable issue where you could conceivably have dozens if not hundreds of records being affected in a very close period of time. I'm thinking about several users importing records or executing some method that loops through a bunch of records.
Plus I'm really trying to get away from IP vars as much as possible. In the original db the best solution has worked out to be my initial idea: I split out the updating of the date & user fields and run that within the Save Record wrapper. I tend to prefer triggers for this sort of thing because it catches changes due to stuff like importing, apply to selection, etc. Save Record is great for While Loops and user inputs but not so much those other cases. It's actually this sort of stuff, custom user info not being readily available, that lead me to work out syncing my user accounts with 4D users. It's a whole 'nuther level of complexity but lets me get out of the password and logon management business along with solid user identification in any native 4D situation. I'm not necessarily promoting that as a solution - just saying it's working for me in one installation. On Wed, Jul 5, 2017 at 8:36 AM, Charles Miller via 4D_Tech < [email protected]> wrote: > Why not an interprocess array on server open connection add and then > remove at end > > Regards > > Chuck > ------------------------------------------------------------ > ------------------------------------ > Chuck Miller Voice: (617) 739-0306 > Informed Solutions, Inc. Fax: (617) 232-1064 > mailto:miller.cjay<AT SIGN>gmail.com <http://gmail.com/> > Brookline, MA 02446 USA Registered 4D Developer > Providers of 4D and Sybase connectivity > http://www.informed-solutions.com > ------------------------------------------------------------ > ------------------------------------ > > > > On Jul 3, 2017, at 6:19 PM, Joaquin Mendes Castro via 4D_Tech < > [email protected]> wrote: > > > > As far as i have been able to learn by trial and error, the first time a > > client connects to the server, it is asigned a User connection ID. This > ID > > is not related to the 4D user, and will not be the same if you quit and > > connect again. As you said, it is more a node connecting to the server. > The > > good thing is that every process launched by that client has this same > User > > connection ID. If you develop a way of matching this ID with your [users] > > table, you will be able to identify in the server who is playing on the > > client side. We do this by launching an special process protected by a > > semaphore which creates a record in the [current_users] table filling a > > filed with the [users] id, and in the On server close connection method, > > another field with the User connection ID. From then on, you just load > this > > record in the On server open connection (you know the User connection ID) > > so you can use it to get the [users] id in triggers. > > ********************************************************************** > 4D Internet Users Group (4D iNUG) > FAQ: http://lists.4d.com/faqnug.html > Archive: http://lists.4d.com/archives.html > Options: http://lists.4d.com/mailman/options/4d_tech > Unsub: mailto:[email protected] > ********************************************************************** > -- Kirk Brooks San Francisco, CA ======================= *The only thing necessary for the triumph of evil is for good men to do nothing.* *- Edmund Burke* ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
