Hi Gino
As you require a number that needs to be unique across all instances, you
will have to maintain a number generator out of the WO Application. For this
you may have to rely on a data generator at database level more than WO and
then assign this new number from the database by using generato
Most systems for no holes use an array of available numbers. Once you
commit that number is no longer in the array, otherwise it stays in
and is available for use.
- James Cicenia
On Feb 6, 2006, at 10:18 AM, Helge Staedtler wrote:
oh, I must have overlooked that there was a restriction exi
oh, I must have overlooked that there was a restriction existing which said
"without any holes". sorry. I would say, that a sequence without any holes
can only be provided by a queuing machanism. I think a timestamp with
milliseconds would do this in 99.99% of all cases. just an idea.
have fun pla
On 06.02.2006, at 16:55 Uhr, Miguel Arroz wrote:
That's not the right way to do this. Don't forget that, at EO
level, you don't even know what are tables... worst, you may not
lock them (unless writing SQL code directly, but that is NOT EO at
all!).
I know that it's not. You're absolute
Hi!
That's not the right way to do this. Don't forget that, at EO
level, you don't even know what are tables... worst, you may not lock
them (unless writing SQL code directly, but that is NOT EO at all!).
You should solve that at the DB level, with stored procedures,
constraints, etc
On 06.02.2006, at 16:36 Uhr, Gino Pacitti wrote:
What about the holding of a value in a table and doing a raw row
fetch and if on committal there is a conflict alert user to change?
I haven't done this. but what about a single table for that and lock
the table (or the row) for a complete tr
What about the holding of a value in a table and doing a raw row
fetch and if on committal there is a conflict alert user to change?
Gino
On 6 Feb 2006, at 15:32, Guido Neitzer wrote:
On 06.02.2006, at 16:08 Uhr, Helge Staedtler wrote:
hmm, I would have a look at the primary keys.
those are
On 06.02.2006, at 16:08 Uhr, Helge Staedtler wrote:
hmm, I would have a look at the primary keys.
those are ensured by EOF and the DB to be unique, so any number
which is
derived from the primarykey (you might e.g. transform an
alphanumeric PK
into a pure number key) should meet your criter
hi Gino,
hmm, I would have a look at the primary keys.
those are ensured by EOF and the DB to be unique, so any number which is
derived from the primarykey (you might e.g. transform an alphanumeric PK
into a pure number key) should meet your criteria.
you could use e.g. EOUtilities.primaryKeyForO
Or (non-EOF solution)...Write a stored procedure to generate it in the DB, triggered on insert. Slap a unique constraint on column, catch exception and deal with.If you need this number in your EOF stack, don't forget to setRefreshesFetchedObjects on the fetchspec (or something like that).
Might wo
On 6 Feb 2006, at 14:27, Gino Pacitti wrote:
Hi All
Any thoughts on how to address this problem
I have a multi instance app that connects to a single data store.
For any user, across the instances, I need to increment a numerical
value newly for each new registered user.
This then has to
Hi All
Any thoughts on how to address this problem
I have a multi instance app that connects to a single data store.
For any user, across the instances, I need to increment a numerical
value newly for each new registered user.
This then has to be saved back to the data store and for there t
12 matches
Mail list logo
