Den 02.12.2015 13:24, skrev Ann Harrison aharri...@ibphoenix.com
[firebird-support]:
>> On Dec 2, 2015, at 6:35 AM, Tim Ward t...@telensa.com [firebird-support]
>> wrote:
>>
>> What about if two concurrent transactions are both trying to *delete*
>> the *same*
On Wed, Dec 2, 2015 at 11:49 AM, Tim Ward t...@telensa.com
[firebird-support] wrote:
>
>
> Yes I do know it's not a real deadlock, I was using the word because I
> knew it would be understood and because, I'm pretty sure?, I've seen it
> in one of the relevant
Thanks for the replies.
Don't worry folks, I'm not going to try this, I was just curious.
Yes I do know it's not a real deadlock, I was using the word because I
knew it would be understood and because, I'm pretty sure?, I've seen it
in one of the relevant error messages.
--
Tim Ward
Thank you. Seems to be a nice idea, but how to implement it?
Is there an easy way to handle this with a linux install scipt or install
shield on windows?
If this is not the case I think I will use an exe to get the information out of
the database. I will use C++ and IBPP, since this is already
We already had this idea ourselfs (I think it's the easiest way). But the
problem is that two files easily can lead to unconsistency.
Since editing the binary firebird dataformat seems not to be a good idea we
will probably ship a little exe with our installer getting the version out of
the
I know that if two concurrent transactions try to make changes to the
same record at the same time one of them gets a deadlock.
What about if two concurrent transactions are both trying to *delete*
the *same* record at once? - from the point of the view of the user's
objectives there's no
> On Dec 2, 2015, at 6:35 AM, Tim Ward t...@telensa.com [firebird-support]
> wrote:
>
> What about if two concurrent transactions are both trying to *delete*
> the *same* record at once? - from the point of the view of the user's
> objectives there's no