Subject | Re: Feature request : Generator tables |
---|---|
Author | Svein Erling |
Post date | 2004-02-23T08:15:44Z |
--- In firebird-support@yahoogroups.com, Jonathan Neve wrote:
trigger with an EXECUTE STATEMENT that could fire the generator of
your choice (although I must admit I have no experience). Creating a
generator is DDL, so this would still have to be done separately, but
provided the generators exists, one stored procedure should be enough
to fire any of them.
Set
> Well, that's fine in many cases, but it depends what your userTrue, there is no way to use the same generator for both.
> wants. If the user wants (as in the example I gave) his invoices to
> be numbered with a distinct counter for every month (and year), this
> isn't possible. So the codes would go : 04010001, 04010002, ...,
> 0401000N, 04020001, 04020002, ..., 0402000M, etc. If there's no
> relationship between the counter for the different months, as in
> this example, then it's no way to use the same generator for both.
> Currently, my only option in such situations is to not make thisI still believe you with Fb 1.5 could create a stored procedure or
> column my PK at all. But still, this doesn't really solve the
> problem, since I then give it a UNIQUE constraint. If the value of
> this column has to be unique, it would still be nice to have the
> sort of generator system I described, so that a counter could be
> maintained in a transaction independant way, based on certain other
> criteria. So what I do now, is query the table to find what seems to
> be the latest value, and then I increment it, and try to insert my
> record. Then, if there's a PK violation, I continue incrementing the
> value and trying to insert until I manage to get through. This works
> ok, but it would be nice to have a simpler way of doing this.
trigger with an EXECUTE STATEMENT that could fire the generator of
your choice (although I must admit I have no experience). Creating a
generator is DDL, so this would still have to be done separately, but
provided the generators exists, one stored procedure should be enough
to fire any of them.
Set