Hi,
Suppose you have a static SDO (Dynamics 1.1A SP3) defined as:
Query: "FOR EACH customer NO-LOCK, FIRST order OF customer NO-LOCK"
Fields: Customer.Name (updateable), Order.OrderStatus (not updateable)
Suppose also that in a write operation somewhere in your logic you need to update the Order.OrderStatus field of the same record
available in the SDO. This must be done in one of the logic slots available within the database transaction, i.e.
writeBeginTransValidate or writeEndTransValidate. As this field is not part of the primary table of the SDO, there is no b_ buffer
for it, so update must be done directly on the order table (using default buffer or any explicit buffer defined for the table).
Looking through bufferCommit procedure (adm2/data.i), the transaction process of a write operation could be somehow resumed as:
DO TRANSACTION:
BeginTransactionValidate -> writeBeginTransValidate
compareDBRow (old_RowObjUpd <-> DB)
assignDBRow (b_RowObjUpd -> DB)
refetchDBRow (DB -> old_RowObjUpd)
EndTransactionValidate -> writeEndTransValidate
END
Based on the previous sequence of execution:
1.If you change the Order.OrderStatus field in writeBeginTransValidate, compareDBRow issues a "Table:Order - Field(s) have been
changed by another user..." error and changes are rejected. This is because we changed the Order.OrdeStatus in the DB and when
comparing to the before-image value of Order.OrderStatus they will differ.
2.If the change of Order.OrderStatus is coded in writeEndTransValidate, changes are saved, but in the following write transaction,
compareDBRow will issue the same "Table:Order - Field(s) have been changed by another user..." and the update will be cancelled.
This is due to having changed the value of Order.OrderStatus in the DB after the execution of refetchDBRow, so that the before-image
is out of sync with the value of Order.OrderStatus left on the DB.
The only workaround we found is just drop the join to the Order table and include a calculated field that represents the
Order.OrderStatus value.
Questions:
1.Shouldn't compareDBRow in bufferCommit get called before BeginTransactionValidate, instead of after, so that possible changes
coded in BeginTransactionValidate do not confuse the comparison?
1.Shouldn't refetchDBRow in bufferCommit get called after EndTransactionValidate, instead of before, so that field values taken into
the before-image to the client are in sync with possible changes made in EndTransactionValidate?
2.Has the bufferCommit procedure changed in Dynamics version 2.0?
Regards,
Ariel.-
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Ariel,
The latest (next) version will call refetchDbRow AFTER
EndTransactionValidate as you suggest. Hopefully you can achieve the same
effect by explicitly setting the RowObjUpd field from the new value in the
order table?
It is fully possible that it would make sense to move compareDbRow before
any of the transaction hooks, but I may overlook something. You could enter
an issue for this.
HÃ¥vard
-Original Message-
Sent: Wednesday, January 29, 2003 5:36 PM
To: ICF Dev
Subject: Question on bufferCommit procedure
Hi,
Suppose you have a static SDO (Dynamics 1.1A SP3) defined as:
Query: "FOR EACH customer NO-LOCK, FIRST order OF customer NO-LOCK"
Fields: Customer.Name (updateable), Order.OrderStatus (not updateable)
Suppose also that in a write operation somewhere in your logic you need to
update the Order.OrderStatus field of the same record
available in the SDO. This must be done in one of the logic slots available
within the database transaction, i.e.
writeBeginTransValidate or writeEndTransValidate. As this field is not part
of the primary table of the SDO, there is no b_ buffer
for it, so update must be done directly on the order table (using default
buffer or any explicit buffer defined for the table).
Looking through bufferCommit procedure (adm2/data.i), the transaction
process of a write operation could be somehow resumed as:
DO TRANSACTION:
BeginTransactionValidate -writeBeginTransValidate
compareDBRow (old_RowObjUpd DB)
assignDBRow (b_RowObjUpd -DB)
refetchDBRow (DB -old_RowObjUpd)
EndTransactionValidate -writeEndTransValidate
END
Based on the previous sequence of execution:
1.If you change the Order.OrderStatus field in writeBeginTransValidate,
compareDBRow issues a "Table:Order - Field(s) have been
changed by another user..." error and changes are rejected. This is because
we changed the Order.OrdeStatus in the DB and when
comparing to the before-image value of Order.OrderStatus they will differ.
2.If the change of Order.OrderStatus is coded in writeEndTransValidate,
changes are saved, but in the following write transaction,
compareDBRow will issue the same "Table:Order - Field(s) have been changed
by another user..." and the update will be cancelled.
This is due to having changed the value of Order.OrderStatus in the DB after
the execution of refetchDBRow, so that the before-image
is out of sync with the value of Order.OrderStatus left on the DB.
The only workaround we found is just drop the join to the Order table and
include a calculated field that represents the
Order.OrderStatus value.
Questions:
1.Shouldn't compareDBRow in bufferCommit get called before
BeginTransactionValidate, instead of after, so that possible changes
coded in BeginTransactionValidate do not confuse the comparison?
1.Shouldn't refetchDBRow in bufferCommit get called after
EndTransactionValidate, instead of before, so that field values taken into
the before-image to the client are in sync with possible changes made in
EndTransactionValidate?
2.Has the bufferCommit procedure changed in Dynamics version 2.0?
Regards,
Ariel.-
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
HÃ¥vard,
Thanks for getting back to me.
When you say "latest (next)" do you mean 2.1?
I could as I understand you state, just call refetchDBRow again after my writeEndTransValidate, and that does solve the problem.
Regards,
Ariel.-
-Original Message-
Sent: Wednesday, January 29, 2003 8:44 PM
To: dev@icf.possenet.org; ICF Dev
Subject: RE: Question on bufferCommit procedure
Ariel,
The latest (next) version will call refetchDbRow AFTER
EndTransactionValidate as you suggest. Hopefully you can achieve the same
effect by explicitly setting the RowObjUpd field from the new value in the
order table?
It is fully possible that it would make sense to move compareDbRow before
any of the transaction hooks, but I may overlook something. You could enter
an issue for this.
HÃ¥vard
-Original Message-
Sent: Wednesday, January 29, 2003 5:36 PM
To: ICF Dev
Subject: Question on bufferCommit procedure
Hi,
Suppose you have a static SDO (Dynamics 1.1A SP3) defined as:
Query: "FOR EACH customer NO-LOCK, FIRST order OF customer NO-LOCK"
Fields: Customer.Name (updateable), Order.OrderStatus (not updateable)
Suppose also that in a write operation somewhere in your logic you need to
update the Order.OrderStatus field of the same record
available in the SDO. This must be done in one of the logic slots available
within the database transaction, i.e.
writeBeginTransValidate or writeEndTransValidate. As this field is not part
of the primary table of the SDO, there is no b_ buffer
for it, so update must be done directly on the order table (using default
buffer or any explicit buffer defined for the table).
Looking through bufferCommit procedure (adm2/data.i), the transaction
process of a write operation could be somehow resumed as:
DO TRANSACTION:
BeginTransactionValidate -writeBeginTransValidate
compareDBRow (old_RowObjUpd DB)
assignDBRow (b_RowObjUpd -DB)
refetchDBRow (DB -old_RowObjUpd)
EndTransactionValidate -writeEndTransValidate
END
Based on the previous sequence of execution:
1.If you change the Order.OrderStatus field in writeBeginTransValidate,
compareDBRow issues a "Table:Order - Field(s) have been
changed by another user..." error and changes are rejected. This is because
we changed the Order.OrdeStatus in the DB and when
comparing to the before-image value of Order.OrderStatus they will differ.
2.If the change of Order.OrderStatus is coded in writeEndTransValidate,
changes are saved, but in the following write transaction,
compareDBRow will issue the same "Table:Order - Field(s) have been changed
by another user..." and the update will be cancelled.
This is due to having changed the value of Order.OrderStatus in the DB after
the execution of refetchDBRow, so that the before-image
is out of sync with the value of Order.OrderStatus left on the DB.
The only workaround we found is just drop the join to the Order table and
include a calculated field that represents the
Order.OrderStatus value.
Questions:
1.Shouldn't compareDBRow in bufferCommit get called before
BeginTransactionValidate, instead of after, so that possible changes
coded in BeginTransactionValidate do not confuse the comparison?
1.Shouldn't refetchDBRow in bufferCommit get called after
EndTransactionValidate, instead of before, so that field values taken into
the before-image to the client are in sync with possible changes made in
EndTransactionValidate?
2.Has the bufferCommit procedure changed in Dynamics version 2.0?
Regards,
Ariel.-
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Allowing any custom code hooks between 'compareDbRow' and 'assignDbRow'
(i.e. moving it before 'beginTransactionValidate') increases the risk of
overriding somebody else's changes to the record by giving up control of
the time interval between 'compare' and 'assign'.
In the case described, the correct action would be for the SDO to avoid
a DB comparison for tables that don't have updatable fields (i.e.
Order).
Regards,
Gikas
-Original Message-
Sent: Wednesday, January 29, 2003 6:44 PM
To: dev@icf.possenet.org; ICF Dev
Subject: RE: Question on bufferCommit procedure
Ariel,
The latest (next) version will call refetchDbRow AFTER
EndTransactionValidate as you suggest. Hopefully you can
achieve the same
effect by explicitly setting the RowObjUpd field from the new
value in the
order table?
It is fully possible that it would make sense to move
compareDbRow before
any of the transaction hooks, but I may overlook something.
You could enter
an issue for this.
HÃ¥vard
-Original Message-
Sent: Wednesday, January 29, 2003 5:36 PM
To: ICF Dev
Subject: Question on bufferCommit procedure
Hi,
Suppose you have a static SDO (Dynamics 1.1A SP3) defined as:
Query: "FOR EACH customer NO-LOCK, FIRST order OF customer NO-LOCK"
Fields: Customer.Name (updateable), Order.OrderStatus (not updateable)
Suppose also that in a write operation somewhere in your
logic you need to
update the Order.OrderStatus field of the same record
available in the SDO. This must be done in one of the logic
slots available
within the database transaction, i.e.
writeBeginTransValidate or writeEndTransValidate. As this
field is not part
of the primary table of the SDO, there is no b_ buffer
for it, so update must be done directly on the order table
(using default
buffer or any explicit buffer defined for the table).
Looking through bufferCommit procedure (adm2/data.i), the transaction
process of a write operation could be somehow resumed as:
DO TRANSACTION:
BeginTransactionValidate -writeBeginTransValidate
compareDBRow (old_RowObjUpd DB)
assignDBRow (b_RowObjUpd -DB)
refetchDBRow (DB -old_RowObjUpd)
EndTransactionValidate -writeEndTransValidate
END
Based on the previous sequence of execution:
1.If you change the Order.OrderStatus field in
writeBeginTransValidate,
compareDBRow issues a "Table:Order - Field(s) have been
changed by another user..." error and changes are rejected.
This is because
we changed the Order.OrdeStatus in the DB and when
comparing to the before-image value of Order.OrderStatus they
will differ.
2.If the change of Order.OrderStatus is coded in
writeEndTransValidate,
changes are saved, but in the following write transaction,
compareDBRow will issue the same "Table:Order - Field(s) have
been changed
by another user..." and the update will be cancelled.
This is due to having changed the value of Order.OrderStatus
in the DB after
the execution of refetchDBRow, so that the before-image
is out of sync with the value of Order.OrderStatus left on the DB.
The only workaround we found is just drop the join to the
Order table and
include a calculated field that represents the
Order.OrderStatus value.
Questions:
1.Shouldn't compareDBRow in bufferCommit get called before
BeginTransactionValidate, instead of after, so that possible changes
coded in BeginTransactionValidate do not confuse the comparison?
1.Shouldn't refetchDBRow in bufferCommit get called after
EndTransactionValidate, instead of before, so that field
values taken into
the before-image to the client are in sync with possible
changes made in
EndTransactionValidate?
2.Has the bufferCommit procedure changed in Dynamics version 2.0?
Regards,
Ariel.-
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Ariel,
It will be in version 2.1.
You could just call refetchDbRow, but I was thinking that you just could
assign
b_order.= order.in the endTransactionValidate. (I'm not sure if it works )
HÃ¥vard
-Original Message-
Sent: Thursday, January 30, 2003 10:54 AM
To: dev@icf.possenet.org
Subject: RE: Question on bufferCommit procedure
HÃ¥vard,
Thanks for getting back to me.
When you say "latest (next)" do you mean 2.1?
I could as I understand you state, just call refetchDBRow again after my
writeEndTransValidate, and that does solve the problem.
Regards,
Ariel.-
-Original Message-
Sent: Wednesday, January 29, 2003 8:44 PM
To: dev@icf.possenet.org; ICF Dev
Subject: RE: Question on bufferCommit procedure
Ariel,
The latest (next) version will call refetchDbRow AFTER
EndTransactionValidate as you suggest. Hopefully you can achieve the same
effect by explicitly setting the RowObjUpd field from the new value in the
order table?
It is fully possible that it would make sense to move compareDbRow before
any of the transaction hooks, but I may overlook something. You could enter
an issue for this.
HÃ¥vard
-Original Message-
Sent: Wednesday, January 29, 2003 5:36 PM
To: ICF Dev
Subject: Question on bufferCommit procedure
Hi,
Suppose you have a static SDO (Dynamics 1.1A SP3) defined as:
Query: "FOR EACH customer NO-LOCK, FIRST order OF customer NO-LOCK"
Fields: Customer.Name (updateable), Order.OrderStatus (not updateable)
Suppose also that in a write operation somewhere in your logic you need to
update the Order.OrderStatus field of the same record
available in the SDO. This must be done in one of the logic slots available
within the database transaction, i.e.
writeBeginTransValidate or writeEndTransValidate. As this field is not part
of the primary table of the SDO, there is no b_ buffer
for it, so update must be done directly on the order table (using default
buffer or any explicit buffer defined for the table).
Looking through bufferCommit procedure (adm2/data.i), the transaction
process of a write operation could be somehow resumed as:
DO TRANSACTION:
BeginTransactionValidate -writeBeginTransValidate
compareDBRow (old_RowObjUpd DB)
assignDBRow (b_RowObjUpd -DB)
refetchDBRow (DB -old_RowObjUpd)
EndTransactionValidate -writeEndTransValidate
END
Based on the previous sequence of execution:
1.If you change the Order.OrderStatus field in writeBeginTransValidate,
compareDBRow issues a "Table:Order - Field(s) have been
changed by another user..." error and changes are rejected. This is because
we changed the Order.OrdeStatus in the DB and when
comparing to the before-image value of Order.OrderStatus they will differ.
2.If the change of Order.OrderStatus is coded in writeEndTransValidate,
changes are saved, but in the following write transaction,
compareDBRow will issue the same "Table:Order - Field(s) have been changed
by another user..." and the update will be cancelled.
This is due to having changed the value of Order.OrderStatus in the DB after
the execution of refetchDBRow, so that the before-image
is out of sync with the value of Order.OrderStatus left on the DB.
The only workaround we found is just drop the join to the Order table and
include a calculated field that represents the
Order.OrderStatus value.
Questions:
1.Shouldn't compareDBRow in bufferCommit get called before
BeginTransactionValidate, instead of after, so that possible changes
coded in BeginTransactionValidate do not confuse the comparison?
1.Shouldn't refetchDBRow in bufferCommit get called after
EndTransactionValidate, instead of before, so that field values taken into
the before-image to the client are in sync with possible changes made in
EndTransactionValidate?
2.Has the bufferCommit procedure changed in Dynamics version 2.0?
Regards,
Ariel.-
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Gikas,
You wrote:
Allowing any custom code hooks between 'compareDbRow' and 'assignDbRow'
(i.e. moving it before 'beginTransactionValidate') increases the risk of
overriding somebody else's changes to the record by giving up control of
the time interval between 'compare' and 'assign'.
I sure agree on this, but... the term "increases" reveals there is already a risk (although lower). Would it be possible to lock up
exclusively all affected records just after the beginning of the transaction and let those be released at the end of the
transaction? This could tend to a no-risk situation of overriding somebody else's changes and would make it possible to move
compareDBRow where necessary. Would this locking-approach bring up undesired side-effects?
In the case described, the correct action would be for the SDO to avoid
a DB comparison for tables that don't have updatable fields (i.e.
Order).
Yes, I think that for this particular case it could be a fair solution.
Regards,
Ariel.-
-Original Message-
Sent: Thursday, January 30, 2003 1:18 PM
To: dev@icf.possenet.org; 'ICF Dev'
Subject: RE: Question on bufferCommit procedure
Allowing any custom code hooks between 'compareDbRow' and 'assignDbRow'
(i.e. moving it before 'beginTransactionValidate') increases the risk of
overriding somebody else's changes to the record by giving up control of
the time interval between 'compare' and 'assign'.
In the case described, the correct action would be for the SDO to avoid
a DB comparison for tables that don't have updatable fields (i.e.
Order).
Regards,
Gikas
-Original Message-
Sent: Wednesday, January 29, 2003 6:44 PM
To: dev@icf.possenet.org; ICF Dev
Subject: RE: Question on bufferCommit procedure
Ariel,
The latest (next) version will call refetchDbRow AFTER
EndTransactionValidate as you suggest. Hopefully you can
achieve the same
effect by explicitly setting the RowObjUpd field from the new
value in the
order table?
It is fully possible that it would make sense to move
compareDbRow before
any of the transaction hooks, but I may overlook something.
You could enter
an issue for this.
HÃ¥vard
-Original Message-
Sent: Wednesday, January 29, 2003 5:36 PM
To: ICF Dev
Subject: Question on bufferCommit procedure
Hi,
Suppose you have a static SDO (Dynamics 1.1A SP3) defined as:
Query: "FOR EACH customer NO-LOCK, FIRST order OF customer NO-LOCK"
Fields: Customer.Name (updateable), Order.OrderStatus (not updateable)
Suppose also that in a write operation somewhere in your
logic you need to
update the Order.OrderStatus field of the same record
available in the SDO. This must be done in one of the logic
slots available
within the database transaction, i.e.
writeBeginTransValidate or writeEndTransValidate. As this
field is not part
of the primary table of the SDO, there is no b_ buffer
for it, so update must be done directly on the order table
(using default
buffer or any explicit buffer defined for the table).
Looking through bufferCommit procedure (adm2/data.i), the transaction
process of a write operation could be somehow resumed as:
DO TRANSACTION:
BeginTransactionValidate -writeBeginTransValidate
compareDBRow (old_RowObjUpd DB)
assignDBRow (b_RowObjUpd -DB)
refetchDBRow (DB -old_RowObjUpd)
EndTransactionValidate -writeEndTransValidate
END
Based on the previous sequence of execution:
1.If you change the Order.OrderStatus field in
writeBeginTransValidate,
compareDBRow issues a "Table:Order - Field(s) have been
changed by another user..." error and changes are rejected.
This is because
we changed the Order.OrdeStatus in the DB and when
comparing to the before-image value of Order.OrderStatus they
will differ.
2.If the change of Order.OrderStatus is coded in
writeEndTransValidate,
changes are saved, but in the following write transaction,
compareDBRow will issue the same "Table:Order - Field(s) have
been changed
by another user..." and the update will be cancelled.
This is due to having changed the value of Order.OrderStatus
in the DB after
the execution of refetchDBRow, so that the before-image
is out of sync with the value of Order.OrderStatus left on the DB.
The only workaround we found is just drop the join to the
Order table and
include a calculated field that represents the
Order.OrderStatus value.
Questions:
1.Shouldn't compareDBRow in bufferCommit get called before
BeginTransactionValidate, instead of after, so that possible changes
coded in BeginTransactionValidate do not confuse the comparison?
1.Shouldn't refetchDBRow in bufferCommit get called after
EndTransactionValidate, instead of before, so that field
values taken into
the before-image to the client are in sync with possible
changes made in
EndTransactionValidate?
2.Has the bufferCommit procedure changed in Dynamics version 2.0?
Regards,
Ariel.-
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Ariel,
We actually lock before we compare, so the word 'increase' was incorrect.
This means that it is somewhat difficult and inefficient to move this
further up/out as we are currently locking and comparing one record at a
time (An SDO with AutoCommit off may update many records). The
beginTransactionValidate happens before we start looping through the
records.
Thanks,
HÃ¥vard
-Original Message-
Sent: Thursday, January 30, 2003 2:10 PM
To: dev@icf.possenet.org
Subject: RE: Question on bufferCommit procedure
Gikas,
You wrote:
Allowing any custom code hooks between 'compareDbRow' and 'assignDbRow'
(i.e. moving it before 'beginTransactionValidate') increases the risk of
overriding somebody else's changes to the record by giving up control of
the time interval between 'compare' and 'assign'.
I sure agree on this, but... the term "increases" reveals there is already a
risk (although lower). Would it be possible to lock up
exclusively all affected records just after the beginning of the transaction
and let those be released at the end of the
transaction? This could tend to a no-risk situation of overriding somebody
else's changes and would make it possible to move
compareDBRow where necessary. Would this locking-approach bring up undesired
side-effects?
In the case described, the correct action would be for the SDO to avoid
a DB comparison for tables that don't have updatable fields (i.e.
Order).
Yes, I think that for this particular case it could be a fair solution.
Regards,
Ariel.-
-Original Message-
Sent: Thursday, January 30, 2003 1:18 PM
To: dev@icf.possenet.org; 'ICF Dev'
Subject: RE: Question on bufferCommit procedure
Allowing any custom code hooks between 'compareDbRow' and 'assignDbRow'
(i.e. moving it before 'beginTransactionValidate') increases the risk of
overriding somebody else's changes to the record by giving up control of
the time interval between 'compare' and 'assign'.
In the case described, the correct action would be for the SDO to avoid
a DB comparison for tables that don't have updatable fields (i.e.
Order).
Regards,
Gikas
-Original Message-
Sent: Wednesday, January 29, 2003 6:44 PM
To: dev@icf.possenet.org; ICF Dev
Subject: RE: Question on bufferCommit procedure
Ariel,
The latest (next) version will call refetchDbRow AFTER
EndTransactionValidate as you suggest. Hopefully you can
achieve the same
effect by explicitly setting the RowObjUpd field from the new
value in the
order table?
It is fully possible that it would make sense to move
compareDbRow before
any of the transaction hooks, but I may overlook something.
You could enter
an issue for this.
HÃ¥vard
-Original Message-
Sent: Wednesday, January 29, 2003 5:36 PM
To: ICF Dev
Subject: Question on bufferCommit procedure
Hi,
Suppose you have a static SDO (Dynamics 1.1A SP3) defined as:
Query: "FOR EACH customer NO-LOCK, FIRST order OF customer NO-LOCK"
Fields: Customer.Name (updateable), Order.OrderStatus (not updateable)
Suppose also that in a write operation somewhere in your
logic you need to
update the Order.OrderStatus field of the same record
available in the SDO. This must be done in one of the logic
slots available
within the database transaction, i.e.
writeBeginTransValidate or writeEndTransValidate. As this
field is not part
of the primary table of the SDO, there is no b_ buffer
for it, so update must be done directly on the order table
(using default
buffer or any explicit buffer defined for the table).
Looking through bufferCommit procedure (adm2/data.i), the transaction
process of a write operation could be somehow resumed as:
DO TRANSACTION:
BeginTransactionValidate -writeBeginTransValidate
compareDBRow (old_RowObjUpd DB)
assignDBRow (b_RowObjUpd -DB)
refetchDBRow (DB -old_RowObjUpd)
EndTransactionValidate -writeEndTransValidate
END
Based on the previous sequence of execution:
1.If you change the Order.OrderStatus field in
writeBeginTransValidate,
compareDBRow issues a "Table:Order - Field(s) have been
changed by another user..." error and changes are rejected.
This is because
we changed the Order.OrdeStatus in the DB and when
comparing to the before-image value of Order.OrderStatus they
will differ.
2.If the change of Order.OrderStatus is coded in
writeEndTransValidate,
changes are saved, but in the following write transaction,
compareDBRow will issue the same "Table:Order - Field(s) have
been changed
by another user..." and the update will be cancelled.
This is due to having changed the value of Order.OrderStatus
in the DB after
the execution of refetchDBRow, so that the before-image
is out of sync with the value of Order.OrderStatus left on the DB.
The only workaround we found is just drop the join to the
Order table and
include a calculated field that represents the
Order.OrderStatus value.
Questions:
1.Shouldn't compareDBRow in bufferCommit get called before
BeginTransactionValidate, instead of after, so that possible changes
coded in BeginTransactionValidate do not confuse the comparison?
1.Shouldn't refetchDBRow in bufferCommit get called after
EndTransactionValidate, instead of before, so that field
values taken into
the before-image to the client are in sync with possible
changes made in
EndTransactionValidate?
2.Has the bufferCommit procedure changed in Dynamics version 2.0?
Regards,
Ariel.-
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
Ariel,
Well, I spoke too soon... :o)
After looking at 'bufferCommit',we actually lock the DB record before we
compare it to RowObjUpd so there's no risk of overriding a changed
record.
So, while we cannot move 'compareDbRow' by itself to the beginnning of
the transaction, your suggestion to move both the record lock and
'compareDbRow' higher up to include 'beginTransactionValidate' seems to
be safe.
As Havard suggested, you should enter an issue in Issuezilla for this.
Regards,
Gikas
-Original Message-
Sent: Thursday, January 30, 2003 2:10 PM
To: dev@icf.possenet.org
Subject: RE: Question on bufferCommit procedure
Gikas,
You wrote:
Allowing any custom code hooks between 'compareDbRow' and
'assignDbRow'
(i.e. moving it before 'beginTransactionValidate') increases
the risk of
overriding somebody else's changes to the record by giving
up control of
the time interval between 'compare' and 'assign'.
I sure agree on this, but... the term "increases" reveals
there is already a risk (although lower). Would it be
possible to lock up
exclusively all affected records just after the beginning of
the transaction and let those be released at the end of the
transaction? This could tend to a no-risk situation of
overriding somebody else's changes and would make it possible to move
compareDBRow where necessary. Would this locking-approach
bring up undesired side-effects?
In the case described, the correct action would be for the
SDO to avoid
a DB comparison for tables that don't have updatable fields (i.e.
Order).
Yes, I think that for this particular case it could be a fair
solution.
Regards,
Ariel.-
-Original Message-
Sent: Thursday, January 30, 2003 1:18 PM
To: dev@icf.possenet.org; 'ICF Dev'
Subject: RE: Question on bufferCommit procedure
Allowing any custom code hooks between 'compareDbRow' and
'assignDbRow'
(i.e. moving it before 'beginTransactionValidate') increases
the risk of
overriding somebody else's changes to the record by giving up
control of
the time interval between 'compare' and 'assign'.
In the case described, the correct action would be for the
SDO to avoid
a DB comparison for tables that don't have updatable fields (i.e.
Order).
Regards,
Gikas
-Original Message-
Sent: Wednesday, January 29, 2003 6:44 PM
To: dev@icf.possenet.org; ICF Dev
Subject: RE: Question on bufferCommit procedure
Ariel,
The latest (next) version will call refetchDbRow AFTER
EndTransactionValidate as you suggest. Hopefully you can
achieve the same
effect by explicitly setting the RowObjUpd field from the new
value in the
order table?
It is fully possible that it would make sense to move
compareDbRow before
any of the transaction hooks, but I may overlook something.
You could enter
an issue for this.
HÃ¥vard
-Original Message-
Sent: Wednesday, January 29, 2003 5:36 PM
To: ICF Dev
Subject: Question on bufferCommit procedure
Hi,
Suppose you have a static SDO (Dynamics 1.1A SP3) defined as:
Query: "FOR EACH customer NO-LOCK, FIRST order OF customer NO-LOCK"
Fields: Customer.Name (updateable), Order.OrderStatus (not
updateable)
Suppose also that in a write operation somewhere in your
logic you need to
update the Order.OrderStatus field of the same record
available in the SDO. This must be done in one of the logic
slots available
within the database transaction, i.e.
writeBeginTransValidate or writeEndTransValidate. As this
field is not part
of the primary table of the SDO, there is no b_ buffer
for it, so update must be done directly on the order table
(using default
buffer or any explicit buffer defined for the table).
Looking through bufferCommit procedure (adm2/data.i), the
transaction
process of a write operation could be somehow resumed as:
DO TRANSACTION:
BeginTransactionValidate -writeBeginTransValidate
compareDBRow (old_RowObjUpd DB)
assignDBRow (b_RowObjUpd -DB)
refetchDBRow (DB -old_RowObjUpd)
EndTransactionValidate -writeEndTransValidate
END
Based on the previous sequence of execution:
1.If you change the Order.OrderStatus field in
writeBeginTransValidate,
compareDBRow issues a "Table:Order - Field(s) have been
changed by another user..." error and changes are rejected.
This is because
we changed the Order.OrdeStatus in the DB and when
comparing to the before-image value of Order.OrderStatus they
will differ.
2.If the change of Order.OrderStatus is coded in
writeEndTransValidate,
changes are saved, but in the following write transaction,
compareDBRow will issue the same "Table:Order - Field(s) have
been changed
by another user..." and the update will be cancelled.
This is due to having changed the value of Order.OrderStatus
in the DB after
the execution of refetchDBRow, so that the before-image
is out of sync with the value of Order.OrderStatus left on the DB.
The only workaround we found is just drop the join to the
Order table and
include a calculated field that represents the
Order.OrderStatus value.
Questions:
1.Shouldn't compareDBRow in bufferCommit get called before
BeginTransactionValidate, instead of after, so that possible changes
coded in BeginTransactionValidate do not confuse the comparison?
1.Shouldn't refetchDBRow in bufferCommit get called after
EndTransactionValidate, instead of before, so that field
values taken into
the before-image to the client are in sync with possible
changes made in
EndTransactionValidate?
2.Has the bufferCommit procedure changed in Dynamics version 2.0?
Regards,
Ariel.-
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org
To unsubscribe, e-mail: dev-unsubscribe@icf.possenet.org
For additional commands, e-mail: dev-help@icf.possenet.org