I think we are trying to complicate something that is simple.

So, let's resume it:

a) Why the newfield?

- This newfield type will be just to help the tedious work to implement Keys
based in Generators.

b) It will be usefull?

- Lot's of people use this kind of "generator related" fields, and this new
field type will save lot's of time for this kind of people.

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.

d) And the people that 'hate' this kind of fields?

I think we can put something on the manual that will explain to this users
that they are free to use it or not.

Notes:

This is a very different approach of 'Autoincrement fields'. We don't need a
autoincrement field. We are just looking for a way to unique identify the
record. We don't care about the value it will have: we just want FB to use
it as we are use to do.
We will not loose the abbility to use the generator outside that trigger.
And the trigger will check if we did something with it, or not.
That's the main reason I propose the name changed from 'AUTOINC' to
'AUTOGEN'. It will be a reference to the generator, not to a 'increment'
field.

This is a "Save Time" field, and time it's (one of) the most precious things
that a programmer could save.

Artur Anjos

>
> I fear we are just trying to substitute a flexible approach we already
> have with something less useful (if also less tedious to implement, I
> admit).
> Should that define a system trigger? Should that trigger fire before or
> after the user defined triggers? Should the user defined triggers be
> able to see/modify the value?
> --
> ____
> _/\/ando
>
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>