On Jul 7, 2006, at 14:07 , Stephan Szabo wrote:
I don't think he is, because I don't think the issue is the SERIAL
behavior, but instead the NOT EXISTS behavior.
I guess I should have been clearer in the issue I was addressing,
which is whether or not a separate transaction could slip in an
On 7/7/06, Scott Marlowe <
[EMAIL PROTECTED]> wrote:
On Fri, 2006-07-07 at 13:07, Stephan Szabo wrote:> On Fri, 7 Jul 2006, Michael Glaesemann wrote:>> >> > On Jul 7, 2006, at 7:55 , Weber, Johann (ISS Kassel) wrote:> >> > > My concern: in a multi threaded environment, can a second thread
> > > in
On Fri, 2006-07-07 at 13:07, Stephan Szabo wrote:
> On Fri, 7 Jul 2006, Michael Glaesemann wrote:
>
> >
> > On Jul 7, 2006, at 7:55 , Weber, Johann (ISS Kassel) wrote:
> >
> > > My concern: in a multi threaded environment, can a second thread
> > > interrupt this statement and eventually insert th
On Fri, 7 Jul 2006, Michael Glaesemann wrote:
>
> On Jul 7, 2006, at 7:55 , Weber, Johann (ISS Kassel) wrote:
>
> > My concern: in a multi threaded environment, can a second thread
> > interrupt this statement and eventually insert the same email
> > address in
> > the table with a different id?
On Jul 7, 2006, at 7:55 , Weber, Johann (ISS Kassel) wrote:
My concern: in a multi threaded environment, can a second thread
interrupt this statement and eventually insert the same email
address in
the table with a different id? Or is this statement atomar?
You're safe. Take a look at the
Guys,
I want to assure that a SQL statement is atomar. It trys to check if an
email address is already found in a table, if yes, it returns the id
field of the entry. If not found, it inserts the entry with the
previously generated increment id and returns - again - the id.
My concern: in a mul
