At 08:11 AM 23/02/2010, unordained wrote:

>---------- Original Message -----------
>From: Helen Borrie <helebor@...>
>> What do you get back from
>> select max(rdb$generator_id) from rdb$generators?
>> ./heLen
>------- End of Original Message -------
>
>Ah-ha! Connecting to the saved database, I get: 32523.
>After backup/restore, which fixed the problem, I get: 657.
>I have scripts that help "build" the database from a meta description, and some
>of the code just attempts DDL ("create generator ...") and in case of failure,
>ignores/logs it. I'm guessing those failures are counting against my max
>generators, and every once in a while I'll have to backup/restore to fix the
>problem?

Something like that, but simpler, I think, either
1) it's using an internal 16-bit integer generator that resets to 0 when it runs out of numbers; or
2) it's using the regular generator to get its id values and you hit the overflow situation past 32767

In case 1) you would get the reported error since you would be trying to duplicate the numbers of existing generator records (including number 1 to 7, which are system-generated and therefore untouchable)

Case 2) seems a simpler explanation of the overflow exception you saw.

Backup/restore obviously does fix the problem that you're making by (apparently) letting an end-user app create generators. Is there any good reason to do it this way? If you must let users create metadata, with identity triggers and all, why not just have one generic 64-bit generator that they all use?

./heLen