Re: Triggers and modified by fields in roll-your-own user schemes
Joaquin, Great suggestion. I'm not going to use it in this case because we don't currently have a session tracking system. But the tip about On server open connection is great. I missed that it fires each time a new process begins. I thought it only ran when initially connecting to the server. I really need to go back and re-read some of fundamental commands more often. After playing with this for about 10 minutes I've got a couple of questions: the user ID - how does this number correlate to 4D users? Or does it refer to 'user' in a more general sense of a 'node' connecting to the server? the connection id is some sort of random value I assume but specific to this particular process. On Mon, Jul 3, 2017 at 9:14 AM, Joaquin Mendes Castro via 4D_Tech < 4d_tech@lists.4d.com> wrote: > We did this by using the On server open connection and On server close > connection database methods. Any process launched by a user session shares > an ID ($1) which can be used to track who is doing what. > > When a user logs into the application, we launch an special process which > records this UserSession_ID and our internal User_ID in a table > ([idsrv_CurrentUsers]). Then, on every new process launched, the On server > open connection method does a query on this table with the UserSession_ID > and loads the user's record as the current for this table. Further on, > triggers just have to use the [idsrv_CurrentUsers]User_ID to know who shot > it. > -- 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:4d_tech-unsubscr...@lists.4d.com **
Triggers and modified by fields in roll-your-own user schemes
We did this by using the On server open connection and On server close connection database methods. Any process launched by a user session shares an ID ($1) which can be used to track who is doing what. When a user logs into the application, we launch an special process which records this UserSession_ID and our internal User_ID in a table ([idsrv_CurrentUsers]). Then, on every new process launched, the On server open connection method does a query on this table with the UserSession_ID and loads the user's record as the current for this table. Further on, triggers just have to use the [idsrv_CurrentUsers]User_ID to know who shot it. There are some tricks to make it work, so if you are interested, I can share more info. > Message: 6 > Date: Fri, 30 Jun 2017 14:58:36 -0700 > From: Kirk Brooks > To: 4D iNug Technical <4d_tech@lists.4d.com> > Subject: Triggers and modified by fields in roll-your-own user schemes > Message-ID: > gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi folks, > > I'm working on an old db. Like begun in v3/pre 4D server old. It has its > own user scheme built in, no 4D users at all (or that matter here). > > The issue is recognizing and tracking modified by/when data. Typically I'd > use a trigger for this but the db runs on 4D server and triggers, as we > know, are executed on the server. So there's no way for the trigger to know > about the user tracked by IP vars. > > Now, the ancestral designers worked around this by writing a SAVE RECORD > wrapper that managed this stuff. The issue is several places where MODIFY > RECORD is called which, of course, doesn't require SAVE RECORD. > > The best solution I've come up with is to split out setting the > Create/Modify action to a separate method. Since this can't run in the > trigger it can run in the SAVE_RECORD wrapper and when MODIFY RECORD is > used I can call it immediately after. Results in a 'double save' but that's > no biggie. > > Anyone else have a better approach for this? > > -- > Kirk Brooks > San Francisco, CA > === > > *The only thing necessary for the triumph of evil is for good men to do > nothing.* > > *- Edmund Burke* > > > -- *** Joaquín Mendes Castro ASEMAT, S.A. tlf: 34-91-4015099 <914%2001%2050%2099> Agustina de Aragón 3, Bajo C fax: 34-91-4018646 <914%2001%2086%2046> 28006 Madrid (SPAIN) e-mail: joaquin.men...@asemat.es *** -- *** Joaquín Mendes Castro ASEMAT, S.A. tlf: 34-91-4015099 Agustina de Aragón 3, Bajo C fax: 34-91-4018646 28006 Madrid (SPAIN) e-mail: joaquin.men...@asemat.es *** ** 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:4d_tech-unsubscr...@lists.4d.com **
Re: Triggers and modified by fields in roll-your-own user schemes
On Sat, 1 Jul 2017 at 8:59 am, Alan Chan via 4D_Tech <4d_tech@lists.4d.com> wrote: > MODIFY RECORD won't save record until you click "Save button". The same > Save_Record Wrapper in Save Button should work without 2nd call. Do I miss > something? What Alan said. When I need to capture other table field or variable values I pack them in an object with their user ID and record UUID in a separate table or the same table And then access that in the trigger as needed. > In fact, this is exactly what we are doing and our app is also evolved > from v3. > > Our wrapper is something like followings > > if(new record or modified record) > > start transaction and new err call > validate all fields locally > if(no error) > log user \\this is what you do to log user > end if > if(no error) > save record > end if > > if(no error) \\no error in trigger > validate transaction > else > cancel transaction > end if > end transaction and end err call > > end if > > Alan Chan > > 4D iNug Technical <4d_tech@lists.4d.com> writes: > >The best solution I've come up with is to split out setting the > >Create/Modify action to a separate method. Since this can't run in the > >trigger it can run in the SAVE_RECORD wrapper and when MODIFY RECORD is > >used I can call it immediately after. Results in a 'double save' but > that's > >no biggie. > > ** > 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:4d_tech-unsubscr...@lists.4d.com > ** -- xxx "There must be ingenuity as well as intention, strategy as well as strength. " ** 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:4d_tech-unsubscr...@lists.4d.com **
Re: Triggers and modified by fields in roll-your-own user schemes
> Le 1 juil. 2017 à 01:47, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> a > écrit : > > Arnaud, > Yeah, I considered that direction too. I ruled it out because it's > introducing a lot of moving parts for the sake of being able to run some > code in a trigger. Since triggers aren't used so far that would be a pretty > big change. I see… Some thought: - in my situation, it was quite easy to do, all processes start with the same piece of code (read only, message off and so on) - I'm not found of a double storage solution - I need user tracking in the 'On Deleting Record Event' too (I'd say more than in modify/add! User is evil ;-) ) > Now, the ancestral designers worked around this by writing a SAVE RECORD > wrapper that managed this stuff. The issue is several places where MODIFY > RECORD is called which, of course, doesn't require SAVE RECORD. Another turnaround (better for future IMHO) is to replace MODIFY RECORD with DIALOG… Your save record wrapper could be used then. -- Arnaud de Montard ** 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:4d_tech-unsubscr...@lists.4d.com **
Re: Triggers and modified by fields in roll-your-own user schemes
Arnaud, Yeah, I considered that direction too. I ruled it out because it's introducing a lot of moving parts for the sake of being able to run some code in a trigger. Since triggers aren't used so far that would be a pretty big change. Making the modified field updates into a separate method looks like the path of least upset. On Fri, Jun 30, 2017 at 4:00 PM, Arnaud de Montard via 4D_Tech < 4d_tech@lists.4d.com> wrote: > > Each time a process begins, I use an EoS (execute on server) method to > write a process variable (an objet) in the twin. As the twin is also the > process that executes the trigger, it will read user from that variable. > > 3 methods: > > a) on startup call User_infosSet > set some properties in c_object <>userInfo_o on client side (user PK, > name, login, machine, ip address, etc.) > > b) when a client process begins, always call User_infosSet_srv > this is the EoS method, it receives <>userInfo_o as $1 and makes a copy of > it in a c_object userInfo_o on server side > > c) when needed (client side, trigger…) call User_infosGet (property) > get some property in the object, > case of >: client side > read property in <>userInfo_o >: server side (twin) > read property in userInfo_o > > Know issue: > - one more process variable on server > - never forget b) (as I sometimes do) > -- 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:4d_tech-unsubscr...@lists.4d.com **
Re: Triggers and modified by fields in roll-your-own user schemes
Alan, Not a bad approach. In this case the MODIFY RECORD commands appear in an otherwise generic EDIT RECORD method so there are numerous forms involved - and they are constructed such that there are multiple ways the record may be caused to be saved. Theoretically they should all funnel back to the SAVE_RECORD wrapper. But they don't. On Fri, Jun 30, 2017 at 3:58 PM, Alan Chan via 4D_Tech <4d_tech@lists.4d.com > wrote: > MODIFY RECORD won't save record until you click "Save button". The same > Save_Record Wrapper in Save Button should work without 2nd call. Do I miss > something? > > In fact, this is exactly what we are doing and our app is also evolved > from v3. > > Our wrapper is something like followings > > if(new record or modified record) > > start transaction and new err call > validate all fields locally > if(no error) > log user \\this is what you do to log user > end if > if(no error) > save record > end if > > if(no error) \\no error in trigger > validate transaction > else > cancel transaction > end if > end transaction and end err call > > end if > > Alan Chan > > 4D iNug Technical <4d_tech@lists.4d.com> writes: > >The best solution I've come up with is to split out setting the > >Create/Modify action to a separate method. Since this can't run in the > >trigger it can run in the SAVE_RECORD wrapper and when MODIFY RECORD is > >used I can call it immediately after. Results in a 'double save' but > that's > >no biggie. > > ** > 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:4d_tech-unsubscr...@lists.4d.com > ** -- 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:4d_tech-unsubscr...@lists.4d.com **
Re: Triggers and modified by fields in roll-your-own user schemes
> Le 30 juin 2017 à 23:58, Kirk Brooks via 4D_Tech <4d_tech@lists.4d.com> a > écrit : > > Hi folks, > > I'm working on an old db. Like begun in v3/pre 4D server old. It has its > own user scheme built in, no 4D users at all (or that matter here). > > The issue is recognizing and tracking modified by/when data. [...] Each time a process begins, I use an EoS (execute on server) method to write a process variable (an objet) in the twin. As the twin is also the process that executes the trigger, it will read user from that variable. 3 methods: a) on startup call User_infosSet set some properties in c_object <>userInfo_o on client side (user PK, name, login, machine, ip address, etc.) b) when a client process begins, always call User_infosSet_srv this is the EoS method, it receives <>userInfo_o as $1 and makes a copy of it in a c_object userInfo_o on server side c) when needed (client side, trigger…) call User_infosGet (property) get some property in the object, case of : client side read property in <>userInfo_o : server side (twin) read property in userInfo_o Know issue: - one more process variable on server - never forget b) (as I sometimes do) Besides that, the trigger knows the user. I can send the code if needed. -- Arnaud ** 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:4d_tech-unsubscr...@lists.4d.com **
Re: Triggers and modified by fields in roll-your-own user schemes
MODIFY RECORD won't save record until you click "Save button". The same Save_Record Wrapper in Save Button should work without 2nd call. Do I miss something? In fact, this is exactly what we are doing and our app is also evolved from v3. Our wrapper is something like followings if(new record or modified record) start transaction and new err call validate all fields locally if(no error) log user \\this is what you do to log user end if if(no error) save record end if if(no error) \\no error in trigger validate transaction else cancel transaction end if end transaction and end err call end if Alan Chan 4D iNug Technical <4d_tech@lists.4d.com> writes: >The best solution I've come up with is to split out setting the >Create/Modify action to a separate method. Since this can't run in the >trigger it can run in the SAVE_RECORD wrapper and when MODIFY RECORD is >used I can call it immediately after. Results in a 'double save' but that's >no biggie. ** 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:4d_tech-unsubscr...@lists.4d.com **
Triggers and modified by fields in roll-your-own user schemes
Hi folks, I'm working on an old db. Like begun in v3/pre 4D server old. It has its own user scheme built in, no 4D users at all (or that matter here). The issue is recognizing and tracking modified by/when data. Typically I'd use a trigger for this but the db runs on 4D server and triggers, as we know, are executed on the server. So there's no way for the trigger to know about the user tracked by IP vars. Now, the ancestral designers worked around this by writing a SAVE RECORD wrapper that managed this stuff. The issue is several places where MODIFY RECORD is called which, of course, doesn't require SAVE RECORD. The best solution I've come up with is to split out setting the Create/Modify action to a separate method. Since this can't run in the trigger it can run in the SAVE_RECORD wrapper and when MODIFY RECORD is used I can call it immediately after. Results in a 'double save' but that's no biggie. Anyone else have a better approach for this? -- 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:4d_tech-unsubscr...@lists.4d.com **
