Assigning same Key as deleted record within a transaction

Jim Labos - infobase (5/15/14 12:44PM)
Jim Labos - infobase (5/15/14 3:42PM)
Alan Chan (5/15/14 4:36PM)
Jim Labos - infobase (5/15/14 5:56PM)
Keisuke Miyako (5/15/14 11:56PM)
Keisuke Miyako (5/16/14 12:47AM)


Jim Labos - infobase (5/15/14 12:44 PM)

fails?

That is the problem actually the record is loaded and in unlocked
state. I
delete it and get no error the proceed to Receive Record. The Save
Record
command then generates a Unique Key violation as though the record
still
existed.

My view on this is that if I am in a transaction then the Key for the
record
I am deleting within that transaction should not be considered as
existing
within the context of the current transaction.

I have not experimented enough to see why this is happening but I am
pretty
certain this is 4D behaviour and not my code as it barely a few lines
of
code. I suppose one way out is to remove the unique key constraint for
the
duration of the transaction but that would be a drastic method.

I could save the record in another table used as a buffer which has a
cloned
field structure/order and receive records in there and then pass each
field's value from that table to the one I want to affect but again
this is
drastic.

The thing I'd like to hear form anyone else is if this is normal
behaviour
in Transactions of any database or just 4D. If only 4D then if I am
correct
this would be considered a bug.

Cheers

Jim Labos - infobase

-----
Jim Labos - infobase
--
View this message in context:

http://4d.1045681.n5.nabble.com/Assigning-same-Key-as-deleted-record-withi
n-a-transaction-fails-tp5730420p5730458.html
Sent from the 4D Tech mailing list archive at Nabble.com.

Jim Labos - infobase (5/15/14 3:42 PM)

fails?

Actually it does find the record saved under transaction! I just tried
this.
That is what I thought so I have looked at my code and I think I not
in sync
with the unique key values. So I think I may be deleting a record with a
different key then the one I am recreating. Therefore in those cases
when I
save the new record it will and should generate a duplicate key error.

I just tried creating a record and doing search and it does as I
thought
find the record. Logical for being in a transaction. I also tried
deleting a
record within a transaction and recreating and saving with same key as
deleted record and I don
t get a key violation. That made me look at my code further and that is
where I see that I cannot be certain the record I am deleting is same
key as
one I am recreating. Haven't tested that but I am certain that is the
problem.

I'll check and give my results here.

Cheers

Jim

-----
Jim Labos - infobase
--
View this message in context:

http://4d.1045681.n5.nabble.com/Assigning-same-Key-as-deleted-record-withi
n-a-transaction-fails-tp5730420p5730463.html
Sent from the 4D Tech mailing list archive at Nabble.com.

Alan Chan (5/15/14 4:36 PM)

fails?

What if you load the original record first before you call receive
record,
that might replace the original record.

Alan Chan

4D iNug Technical <4d_tech@... writes:
color><param>00000,0000,DDEE/param>(( I posted this to the 4D list
instead of the 4DTech subforum. Sorry for
duplication)

I need to synchronize some records on a remote database (non client
server)
with a second database. I use Send Record and then save the document
into
a
BLOB that is then received and converted back to records on the local
database (Receive Record). This is working 100% so no need to change.
Both
databases have the same ID/Key values for each record.

Receive Record cannot simply be used as I have to delete the original
and
only then can I replace otherwise I get a Unique Key violation. I don't
want
to delete in case I need to roolback because of Locked status etc.. So
?I
start a transaction then delete the record and then if not locked I
proceed
with Receive Record and Save Record.

However I still get a Unique Key violation and so 'am unable to save
and
have to cancel transaction.
This is first time I ever replace the Key value with same within a
transaction so I am not sure if it is normal 4D behavior or not.

I figure if I delete a record within a transaction that record should
not
cause a Duplicate Key error within that transaction. I know there are
workarounds but I'd like to try this simple way first before I resort
to
some other way.
/color>

Jim Labos - infobase (5/15/14 5:56 PM)

fails?

Yes I was relieved to confirm that too. For a minute there I wasn't
about it
because I had never done that particular thing before.

It all works logically.

Thanks for steppin' in and helping clarify this.

-----
Jim Labos - infobase
--
View this message in context:

http://4d.1045681.n5.nabble.com/Assigning-same-Key-as-deleted-record-withi
n-a-transaction-fails-tp5730420p5730470.html
Sent from the 4D Tech mailing list archive at Nabble.com.

Keisuke Miyako (5/15/14 11:56 PM)

fails?

I don?=A2?=82¨=E2&Ntilde;¢t have a definitive answer to your
question,
but as far as I know, query inside a transaction will NOT find a record
created within that transaction

if a record created inside a transaction does not exist in the database
until the transaction is validated,
then I would assume that the same applies to deletion as well.

I mean, the record still exists for other processes outside that
transaction,
so it would seem logical to over-write that existing key, or create a
new
key.

On 2014/05/16 4:44, "Jim Labos - infobase" <jlabos@...
wrote:

color><param>00000,0000,DDEE/param>MMy view on this is that if I am in
a transaction then the Key for the
record
I am deleting within that transaction should not be considered as
existing
within the context of the current transaction.
/color>

Keisuke Miyako (5/16/14 12:47 AM)

fails?

saved, yes, but created too?

On 2014/05/16 7:42, "Jim Labos - infobase" <jlabos@...
wrote:

color><param>00000,0000,DDEE/param>AActually it does find the record
saved under transaction!
/color>

Reply to this message

Summary created 5/16/14 at 2:33AM by Intellex Corporation

Comments welcome at: feedback@intellexcorp.com