This content has been marked as final. Show 18 replies
No, it can't figure out if you haven't used a sequence(s). You would have to do that investigation yourself. I don't have access to my Oracle Lite boxes today, but when I get back to them, I will send you a query that will give you a hint about how to achieve what you need.
Yes, so each user will get a new range. So, first user gets 1-50, next user gets 51-100, etc. User 1 is dropped and created again, they will get a new range. If they they meet the threshold criteria, they will be advanced to the next available range as well.
Thank you very much for the reply.
My case is:
A user with the range of sequences, 1778000 to 1779000.
On 11-16-2010, the user is assigned a new post with another new sequence. The range of the new sequence is from 421000 to 422000.
Correct me if I'm wrong:
This may not be possible because the above sequence and have used this range of sequences.
So, your sequence range went backwards?
Yes, we have seen us.
But we believe that this can not be
i apologize but i didnt understand exactly the issue.
we have sequence a which gave the user a window, then the user gets a new sequence b with a new window and the sequence a is deleted.
logically each sequence has its own set of numbers, window etc. so the second sequence should start from 1 (if you had declared 1 as starting when you created it).
each sequence works separate and gives its own window to the users based on what are its settings when you created it. so yes user might had sequence a with window 1million->1,5 million
and sequence b with window 0,5million->1million as a is not the same as b and the sequences have diffrent windows and diffrent set of numbers.
btw you can execute the following query in the msql.exe (or through your program) and get the next value.
SELECT mysequencea.NEXTVAL FROM DUAL
we use many sequences in our programs and each has its own numbers, e.g. user1 might have window 40-60 on sequence a, 2000-2300 on sequence b and 500000-650000 on sequence c. if we delete one of the sequences the other will not get affected.
was my post any help?:)
In your case:
if you create a new user, and assigned a new sequence "D", the new sequence can not start with "1", or take a smaller range "650000" which is the last window caught because otherwise, users to insert into the database will have the problem of "CONFLICT DETECTED. "
this looks like a bug?ill have to check it out to verify this, but i have the impression that in my olite 10.3.0.3 it doesnt happen. looks strange, please open a service request.
btw when you mean comflict detected you mean that the user creates two sequences and uses them as primary key values for the same table or for diffrent tables?i was talking that each sequence is used from our app
as primary keys for diffrent tables not the same. it makes sence if you use them for the same, but this wouldnt be a bug but a misuse of the sequence concept.
The problem, "Conflict Detected" is when a user uses the same sequence at two different times.
We usually occurs when the user returns to reinstall a device, and has not been dismissed and discharged from the server.
In this case we have observed that assigns the same sequence window.
One question: What in your opinion, the correct use of the sequences?
with the correct use i was referring that since we (most of us) use the sequences in order to retrieve primary key values, we should use one sequence for primary key values per table, we shouldnt use two sequences for the same primary key, nor should se delete a sequence for primary key a and create a new one (from 0) since the values will overlap , therefore we will have the conflict detection->data already exists.
but im not sure if that is in your case.
the conflict detected occurs on the synchronization? is it placed in the error queue or it doesnt sync at all?if it is placed in the error queue what is the message shown in the mobile manager?
When we read the documentation, we understood that:
If I have a string "A" for table "X ".
Later, if I create a script "B" on the table "X ".
The sequence "B", as the latter will catch the next window sequences.
Do you think this is?
you mean sequence a and sequence b right? well first of all (at least the way i do it through the mobile workbench) you dont declare somewhere that the sequence a is for table x.
we do it through our c sharp/vb etc code. so at least through the mobile workbench olite doesnt know and shouldnt know in my opinion that sequence a is for table x or for table y etc.
now if you create a second sequence and use it then (at least if you create them through the mdw ) it will not get the last window. olite isnt that smart at least from my experience . now you mentioned in your last post the "script" and i have nerver used scripts since we prefer to do through code.
if you want you can see what is the last window (check the mobileadmin table for the sequences ) and then create the new one through the mdw by setting the starting value as the immediatly next value.
I think we do not understand.
My scheme is as follows:
We have a publication, eg "Pub_1. "
This publication Pub_1 "contains several items listed.
In addition, this publication has many associated sequences that elements of publication.
We create a new publication "Pub_2" with the same elements of publication of Pub_1. "
Create new sequences for publication "Pub_2. "
Do new sequences of "Pub_2" take into account the range of windows that have been used to "Pub_1?
since we are talking about diffrent sequences in diffrent publications that obvious have diffrent sequence names then the answer is from my experience no , one sequence does not take into account the other's sequence range of windows.if in your pc it does then perhaps there is some kind of bug greg?
So you can not have two streams on the same table?
Otherwise. When When we uninstalled a user of a device, and re-install the user, OLITE given the same sequence window right?
If the user information has already been synchronized for the first time, the second time, when i synchronize the second time, will have the same primary keys. This is a mistake, right?