See the archive. Basically I don't think you should be replicating the system like this.
Jim > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of David McGehee > Sent: Monday, August 02, 2010 2:51 PM > To: [email protected] > Subject: RE: Trying to avoid trigger recursion in a jBASE system > > No I did not see your reply. You are advising me not to do what? > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Jim Idle > Sent: Monday, August 02, 2010 4:16 PM > To: [email protected] > Subject: RE: Trying to avoid trigger recursion in a jBASE system > > Did you not see my reply advising you not to do this? > > Jim > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > Behalf > > Of David McGehee > > Sent: Monday, August 02, 2010 9:58 AM > > To: [email protected] > > Subject: RE: Trying to avoid trigger recursion in a jBASE system > > > > I posted this last week but I never say it on line so either it was > blocked or ?? > > > > We use triggers to keep our co-location in sync on a hot basis. We > have a > > somewhat more Complex situation in that ALL of our jbase files are > kept in > > sync this way. To manage this, And in order to preclude recursion, > our > > common trigger creates a key describing the file, record Key, and > operation > > (write, clear, delete) and writes the record with that key into a > common > file > > at The incurring site. A separate process is WAKED and writes the > available > > records to the corresponding File at the other site. There a process > which > > was started at port 4999 writes the transported record(s) to the > target > File. > > The trigger code is written such that it checks the process port and > if > > 4500, > > ignores the trigger trip and exits. > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > Behalf > > Of LWhite > > Sent: Monday, August 02, 2010 10:50 AM > > To: jBASE > > Subject: Re: Trying to avoid trigger recursion in a jBASE system > > > > If a second post shows up I apologize. I had a mishap with the tab > key. :) > > > > OK, Thanks for the replies. I am going to be looking up a lot of what > you > > mentioned. > > > > Maybe if I try to explain the situation again you might see something > that > I > > didn't properly express the first time. > > > > I have a system with a file named IM (item master) > > > > There are both basic and PROC programs accessing it. > > > > Management has decided that we need to be able to have one company > > write code and distribute it to all of the other entities. > > > > We have done this before by using an include file that each entity > adjusted > > to fit their individual file names and order of attributes. > > Example being that we all store an English part name in the IM but not > in > the > > same attribute. > > > > Operations has decided that we will have all companies move to the > same > > file structure. So every company will now have a MPF (manufacturing > > product file) and that it will have the part name in attribute 2. For > some > > reason they will not continue using the include file. I cannot explain > why. I > > have not had it explained to me. > > > > Global code is being worked on. We must use it and we must have the > file > > structure set up by a specific date. > > > > However, They do not want us to touch every program that currently > > accesses the files that have a global equivalent. Since they will be > moving to > > one process they want time to evaluate each portion. We still have to > deploy > > part of it now. > > > > Our idea was to create triggers on the files to keep the local and > global > files in > > sync. Triggers are not required by anything. Any idea that someone > believes > > is better will be looked at. > > > > I am just a code monkey. I am doing what I have been told to do and we > are > > not given an option on the implementation of the code or the > structure. > > > > I am going to go look up transaction journaling and activeMQ. > > Thanks. > > > > -- > > Please read the posting guidelines at: > > http://groups.google.com/group/jBASE/web/Posting%20Guidelines > > > > IMPORTANT: Type T24: at the start of the subject line for questions > specific > > to Globus/T24 > > > > To post, send email to [email protected] To unsubscribe, send > email > > to [email protected] > > For more options, visit this group at > > http://groups.google.com/group/jBASE?hl=en > > > > -- > > Please read the posting guidelines at: > > http://groups.google.com/group/jBASE/web/Posting%20Guidelines > > > > IMPORTANT: Type T24: at the start of the subject line for questions > specific > > to Globus/T24 > > > > To post, send email to [email protected] To unsubscribe, send > email > > to [email protected] > > For more options, visit this group at > > http://groups.google.com/group/jBASE?hl=en > > -- > Please read the posting guidelines at: > http://groups.google.com/group/jBASE/web/Posting%20Guidelines > > IMPORTANT: Type T24: at the start of the subject line for questions specific > to Globus/T24 > > To post, send email to [email protected] To unsubscribe, send email > to [email protected] > For more options, visit this group at > http://groups.google.com/group/jBASE?hl=en > > -- > Please read the posting guidelines at: > http://groups.google.com/group/jBASE/web/Posting%20Guidelines > > IMPORTANT: Type T24: at the start of the subject line for questions specific > to Globus/T24 > > To post, send email to [email protected] To unsubscribe, send email > to [email protected] > For more options, visit this group at > http://groups.google.com/group/jBASE?hl=en -- Please read the posting guidelines at: http://groups.google.com/group/jBASE/web/Posting%20Guidelines IMPORTANT: Type T24: at the start of the subject line for questions specific to Globus/T24 To post, send email to [email protected] To unsubscribe, send email to [email protected] For more options, visit this group at http://groups.google.com/group/jBASE?hl=en
