Subject | Re: [ib-support] Idea for a new field type for FB 2,0 or IB 7? |
---|---|
Author | Paul Schmidt |
Post date | 2001-11-22T14:50:08Z |
On 21 Nov 2001, at 23:05, Artur Anjos wrote:
someone to set another trigger to fire before hand, could be useful,
since it could allow you to set this value using another trigger,
sometimes but not other times.
someone on the FB team can work out the details, of what to call
it, and how to really implement it. Although this thread goes a long
way towards figuring out some of the details.
weeks as a new thread dealing with serial number generators.
Paul
Paul Schmidt
Tricat Technologies
paul@...
www.tricattechnologies.com
>Okay, although we want things as flexable as possible, so allowing
> Hi Paul
>
> > As the guy who started this war last week....
> I'm glad you start it :). That was a GREAT idea!
>
> > > c) How it should be implemented?
> > >
> > > The way people use it mostly, in the trigger Before Insert. So, I
> > > think this should be implemented as a system trigger. The priority
> > > should be Before any definned triggers, so the user can take
> > > control of the value.
> >
> > Not sure I agree, it should be a user trigger with a priority of
> > 100, this way the programmer can create and fire other triggers both
> > before and after. They could even drop in a replacement trigger if
> > they want to do something fancy. Using the field as a quick way to
> > get something defined.
>
> I still don't agree with you. I think the best way it's the trigger to
> fire ALWAYS before the user triggers. That's the way we use it mostly,
> and that's the way we are expecting it to be. The abillity to let that
> trigger do something or not it's controled by setting some value
> before (you can even set him to some negative value to do that fancy
> work). I think it's better to have a rule here, that start to worry
> about the priority of that trigger. Changes will be 'exceptions to the
> rule', and you can control that exceptions before posting. Keep it
> simple.
someone to set another trigger to fire before hand, could be useful,
since it could allow you to set this value using another trigger,
sometimes but not other times.
> > Okay, how about we use IDENTITY instead, that would be moreI don't really care what we call it, I just suggested the mechanism,
> > self-documenting that it's used to identify records. I just said
> > AutoInc because some of the stuff I am working on uses Btrieve.
>
> The AUTOGEN suggestion was to remember that it's using a generator.
> The word AUTOINC will bring us some problems in the future for users
> to expect that numbers to be sequential.
>
someone on the FB team can work out the details, of what to call
it, and how to really implement it. Although this thread goes a long
way towards figuring out some of the details.
> > As for a true series type Auto incrementing field, that would beOkay, I'll drop that part, and you can start it up again in a couple of
> > nice, but should probably be implemented as a serial generator, that
> > is a generator that guarantees there are no holes in the series, we
> > could then use a similar mechanism.
> >
> I think this is another story. If we are going to speak about it at
> the same time, everybody will be confuse. There was already some
> people in this list that do not understand your idea, and keep
> thinking of this new field as a 'AUTOINC' field. I need in my
> applications serial sequential fields (invoice numbers, for example),
> and I will love to start a new discussion about this. Could you please
> delay this new discussion? ;)
>
weeks as a new thread dealing with serial number generators.
Paul
Paul Schmidt
Tricat Technologies
paul@...
www.tricattechnologies.com