I think I need to clarify that I am able to reproduce in a round about way the problem that is happening when the application is running. I did this by just firing the stored procedure in the backend and creating a blocking of the table.

What is happening in the application is that on a certain page in the application a user has the choice to have one order created with Ordererid = 4, or 8 or two orders created by selecting both 4 and 8. Whwn they select only 4 or 8 the stored proc is called only once and so there is no problem. When they select the combination 4 and 8 the procedure is called twice once with Ordererid = 8 followed immediately with a call with Ordererid = 4. Now they expect to get the orderid's back in that sequence the one for 8 first and the one with 4 later. But when there is a little blocking, they get the results in the reverse order. One thing that I noticed was that whewnever this happens, the Orderdate on the two orders is identical, upto the millisecond. My first question is: why are the dates identical upto the millisecond? Can we do any thing with any setting so these two orders fired through the same login by the same person one afetr the other in the code return results in the right sequence.

Sorry for confusing you by making it look like two different users are involved, I had to do that to create a block and simulate the problem in the backend.

I am telling the developers that we should return the ordererid and the orderid from the proc and they should look for the ordererid as well as the orderid in the result being returned and then they would always associate them correctly regardless of the order in which they are returned. what they are doing is just looking at the orderid returned and assuming the first one is for 8 and the second for 4.

Do you think this is a good suggedtion. What do I tell them when they say : How come two Orders created have the exact same time of creation upto the milliseconds, when they were called one after the other in the code.

Thanks.