Skip to main content

Hi,

I saw this kind of programming, which somehow confused me. Although I wouldn't program like this, it worked.

clear/e "mytable"
key.mytable = keyValue
retrieve/e "mytable"
val1.mytable = "dddffgg"
val2.mytable = "ghhtlrgt"
store/e "mytable"
if($status>=0)
  activate OtherFormOrService.AddOtherFields(keyValue, outStat)
  ;some checks, but lets ignore those
  commit
else
  rollback
endif


;In OtherFormOrService
Operation AddOtherFields
params
  numeric  P_KeyVal   : IN
  numeric  P_Outstat  : OUT
endparams

clear/e "mytable"
key.mytable = P_Keyval
retrieve/e "mytable"
val3.mytable = "hjjjkk"
val4.mytable = "asxcccdf"
store/e "mytable"
P_Outstat = $status
end; AddOtherFields

Any opinions, is it correct to add values from another form/service by doing a new retrieve/store without commit, as the calling form already has started a store on the same table-record?

Regards RogerW.


Hi,

I saw this kind of programming, which somehow confused me. Although I wouldn't program like this, it worked.

clear/e "mytable"
key.mytable = keyValue
retrieve/e "mytable"
val1.mytable = "dddffgg"
val2.mytable = "ghhtlrgt"
store/e "mytable"
if($status>=0)
  activate OtherFormOrService.AddOtherFields(keyValue, outStat)
  ;some checks, but lets ignore those
  commit
else
  rollback
endif


;In OtherFormOrService
Operation AddOtherFields
params
  numeric  P_KeyVal   : IN
  numeric  P_Outstat  : OUT
endparams

clear/e "mytable"
key.mytable = P_Keyval
retrieve/e "mytable"
val3.mytable = "hjjjkk"
val4.mytable = "asxcccdf"
store/e "mytable"
P_Outstat = $status
end; AddOtherFields

Any opinions, is it correct to add values from another form/service by doing a new retrieve/store without commit, as the calling form already has started a store on the same table-record?

Regards RogerW.


Hi Roger

As long as the two instances belong to the same database connection/transaction, this is no problem at all.
A new database connection is created as you issue a newinstance "xyz",v_inst,"TRANSACTION=TRUE"
So if one not using this special "newinstance" you are always in the same connection to the database.
And this is also SQL conform, between BEGIN TRANS and COMMIT you can do whatever you want, even update a row a second time 🙂

Ingo




Hi Roger

As long as the two instances belong to the same database connection/transaction, this is no problem at all.
A new database connection is created as you issue a newinstance "xyz",v_inst,"TRANSACTION=TRUE"
So if one not using this special "newinstance" you are always in the same connection to the database.
And this is also SQL conform, between BEGIN TRANS and COMMIT you can do whatever you want, even update a row a second time 🙂

Ingo




One probably has to think of it as: "Store" puts the values to some "temporary context" which is sent to the database as commit is done.

But what about the second retrieve, does it fetch the values from the "temporary context" or directly from the database? Eg. if it fetches directly from the database, one has to be careful about val1 and val2....

Regards RogerW. 

Hi Roger

As long as the two instances belong to the same database connection/transaction, this is no problem at all.
A new database connection is created as you issue a newinstance "xyz",v_inst,"TRANSACTION=TRUE"
So if one not using this special "newinstance" you are always in the same connection to the database.
And this is also SQL conform, between BEGIN TRANS and COMMIT you can do whatever you want, even update a row a second time 🙂

Ingo




Hi Roger

This depends on the DBMS,
Some stores differences in a separate "temp" database and on commit this will copied into the "main" database, others stores it direct into the main database but keep track about the modifications so it could rollback the transaction

But in all systems, this should be transparent to the database user (i.e the UnifAce DBMS-driver)
A call by a "component" in the same transaction (and of cource same connection) sees the data as if they are already commited.
An other transaction (maybe the same application) sees only the modifiction, that an  isolation level allows to see.

Have a look at the documentation about "isolation level" (UnifAce and DBMS)

Ingo

Hi,

I saw this kind of programming, which somehow confused me. Although I wouldn't program like this, it worked.

clear/e "mytable"
key.mytable = keyValue
retrieve/e "mytable"
val1.mytable = "dddffgg"
val2.mytable = "ghhtlrgt"
store/e "mytable"
if($status>=0)
  activate OtherFormOrService.AddOtherFields(keyValue, outStat)
  ;some checks, but lets ignore those
  commit
else
  rollback
endif


;In OtherFormOrService
Operation AddOtherFields
params
  numeric  P_KeyVal   : IN
  numeric  P_Outstat  : OUT
endparams

clear/e "mytable"
key.mytable = P_Keyval
retrieve/e "mytable"
val3.mytable = "hjjjkk"
val4.mytable = "asxcccdf"
store/e "mytable"
P_Outstat = $status
end; AddOtherFields

Any opinions, is it correct to add values from another form/service by doing a new retrieve/store without commit, as the calling form already has started a store on the same table-record?

Regards RogerW.


This technique is often used to make multiple updates to related data, then commit all changes as one atomic transaction, or rollback all stores in the event of an error, ensuring data consistency. Just be aware of that some file-system based non-SQL storage connectors don't support commit & rollback, although most should. If you move to web in future, you will need to ensure that this all happens in one atomic transaction with no postbacks (e.g. UI actions such as a button presse) between the stores and commit.

Terms & ConditionsAccessibility statement