On 1 September 2011 14:19, Milan Babuskov <milanb@...> wrote:

> **
>
>
> Nick Upson wrote:
> > looking at the logs for other processes, all of the last four occurrances
> > happened at the same time as an isql session was run against the original
> > database.
> > I can't think why there is any need for this isql session and the gbak
> > session creating the new database to interact via the lock manager but
> the
> > timing is exact to the second for all four.
> >
> > I shall look further back to see if this holds true for earlier sessions.
>
> My guess is that isql also uses a connection string without
> "localhost:". Take a look at process list (ps command) and you will
> probably see two lock managers running under different Linux user accounts.
>
> Try adding "localhost:" to ISQL as well and it should work fine.
>
> HTH
>

isql connection string already uses localhost, process list only shows one
copy of lock manager

and remember, the gbak is creating one database while the isql session is
causing an update in another

--
Nick Upson (01799 533252)


[Non-text portions of this message have been removed]