Uniface on GitHub
Product (releases and patches)
Reported Issues (old)
Fixes and Updates
I saw this kind of programming, which somehow confused me. Although I wouldn't program like this, it worked.
key.mytable = keyValue
val1.mytable = "dddffgg"
val2.mytable = "ghhtlrgt"
activate OtherFormOrService.AddOtherFields(keyValue, outStat)
;some checks, but lets ignore those
numeric P_KeyVal : IN
numeric P_Outstat : OUT
key.mytable = P_Keyval
val3.mytable = "hjjjkk"
val4.mytable = "asxcccdf"
P_Outstat = $status
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?
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....
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
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.
© 2020 Uniface Privacy & Cookies | Privacy Statement | Legal