Subject | Re: [IBO] Generator values not udpated |
---|---|
Author | Lester Caine |
Post date | 2008-11-07T07:27:31Z |
Helen Borrie wrote:
The numbers are being incremented and stored starting with the correct 'next
number' given by the generator, but the generator value itself is not being
used by the application - so is not actually updated.
Some sort of caching 'intelligence' in
lPersonID := FIBConn.Gen_ID('GEN_PERSON_ID', 1);
where it is seeded correctly but does not actually generate SQL code back to
the database to update 'GEN_PERSON_ID'.
So the generator is not being 'reverted' but rather never advanced? Which of
cause would create a major problem if two users are both inserting!
That a better description of the problem Ed?
Ed - I prefer to let the Firebird insert these values using a trigger. Ok as
long as you don't need the value in other tables, but more of a problem if you
need to use it as a key to records in detail tables.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php
> At 03:08 PM 7/11/2008, you wrote:Helen - it SOUNDS like the generator is not actually being used?
>>> Right. Generators are running outside of transaction control.
>> that's what I thought.
>>
>>> But you can decrement a generator value by using a negativ number
>>> as increment. Perhaps this happens somewhere?
>> nope. never even crossed my mind--nor would I let code like that even
>> be played with in my main application. (Anything of that nature get's
>> done outside of the application, in testing apps).
>>
>>> Although, that the numbers in the tables are correct, but the
>>> generator values are not, sounds weird, except you are fiddling
>>> around with decrementing generators, perhaps by accident.
>> it's really strange because the import utility that the person was
>> using imports data into 4 different tables. All 4 tables had problems
>> with their generators being reverted to what it looked like they had
>> been prior to the import.
>>
>> This is the second time in a year I've seen this--happened to someone
>> elses database. Have thousands of users, probably 10-20 users who use
>> the import utility on a somewhat regular basis.
>
> Hmmm, Ed, you need to clarify what the actual problem is that's being observed:
The numbers are being incremented and stored starting with the correct 'next
number' given by the generator, but the generator value itself is not being
used by the application - so is not actually updated.
Some sort of caching 'intelligence' in
lPersonID := FIBConn.Gen_ID('GEN_PERSON_ID', 1);
where it is seeded correctly but does not actually generate SQL code back to
the database to update 'GEN_PERSON_ID'.
So the generator is not being 'reverted' but rather never advanced? Which of
cause would create a major problem if two users are both inserting!
That a better description of the problem Ed?
Ed - I prefer to let the Firebird insert these values using a trigger. Ok as
long as you don't need the value in other tables, but more of a problem if you
need to use it as a key to records in detail tables.
--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php