[firebird-support] NEXT VALUE FOR on Firebird 3.0.1 32bit Windows 7 32bit

[Roland Turcan [e-mail] [firebird-support]]

Hello firebird-***@yahoogroups.com!

I have installed new clean database to new customer having FB3.0.1
32bit running on Windows7Pro 32bit. He was complaining that he is not
able to add new record into some parts of our software. I have
connected to his computer and made backup/restore and aligned all
generators to MAX(ID) to be sure they are correct. But he still had
some troubles then I started to investigate what the hell is going on.
I have found, that on his "server" is NEXT VALUE FOR not incrementing
generator value, but places where GEN_ID is used instead are working
fine.
I have tried to reproduce this on 32bit XP with the same version of
FB, but in my case it was running fine.

Does anybody have this kind of trouble?

PS: Until I find the reason for this trouble I had to change all NEXT
VALUE FOR to GEN_ID as I was using it for years.

[Dmitry Yemanov [e-mail] [firebird-support]]

Post by Roland Turcan ***@rotursoft.sk [firebird-support]
I have installed new clean database to new customer having FB3.0.1
32bit running on Windows7Pro 32bit. He was complaining that he is not
able to add new record into some parts of our software. I have
connected to his computer and made backup/restore and aligned all
generators to MAX(ID) to be sure they are correct. But he still had
some troubles then I started to investigate what the hell is going on.
I have found, that on his "server" is NEXT VALUE FOR not incrementing
generator value, but places where GEN_ID is used instead are working
fine.
I have tried to reproduce this on 32bit XP with the same version of
FB, but in my case it was running fine.
Does anybody have this kind of trouble?

Check RDB$GENERATOR_INCREMENT inside RDB$GENERATORS. NEXT VALUE FOR uses
the increment stored inside the system table.


Dmitry




------------------------------------

------------------------------------

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Visit http://www.firebirdsql.org and click the Documentation item
on the main (top) menu. Try FAQ and other links from the left-side menu there.

Also search the knowledgebases at http://www.ibphoenix.com/resources/documents/

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/firebird-support/

<*> Your email settings:
Individual Email | Traditional

<*> To change settings online go to:
http://groups.yahoo.com/group/firebird-support/join
(Yahoo! ID required)

<*> To change settings via email:
firebird-support-***@yahoogroups.com
firebird-support-***@yahoogroups.com

<*> To unsubscribe from this group, send an email to:
firebird-support-***@yahoogroups.com

<*> Your use of Yahoo Groups is subject to:
https://info.yahoo.com/legal/us/yahoo/utos/terms/

[Mark Rotteveel [e-mail] [firebird-support]]

Post by Dmitry Yemanov ***@users.sourceforge.net [firebird-support]
Check RDB$GENERATOR_INCREMENT inside RDB$GENERATORS. NEXT VALUE FOR uses
the increment stored inside the system table.

I noticed something interesting, when restoring a Firebird 2.5 database
to Firebird 3.0, only user generators (RDB$SYSTEM_FLAG = 0) get a value
of 1 in RDB$GENERATOR_INCREMENT, system generators get 0. Is that
intentional?

Mark

[Dmitry Yemanov [e-mail] [firebird-support]]

Post by Mark Rotteveel ***@lawinegevaar.nl [firebird-support]
I noticed something interesting, when restoring a Firebird 2.5 database
to Firebird 3.0, only user generators (RDB$SYSTEM_FLAG = 0) get a value
of 1 in RDB$GENERATOR_INCREMENT, system generators get 0. Is that
intentional?

System generators are not transferred in backup, they're recreated from
scratch when a database is being created during restore. And you cannot
explicitly issue either GEN_ID or NEXT VALUE for them, the engine itself
increments them at the low level, without looking at
RDB$GENERATOR_INCREMENT.

So I believe it's absolutely OK, although possibly looking weird.


Dmitry