cool hit counter PL/SQL and SQLPLUS query results are not the same - never forget to COMMIT!_Intefrankly

PL/SQL and SQLPLUS query results are not the same - never forget to COMMIT!

Copyright: This is an original post by the blogger and may not be reproduced without the blogger's permission.

Have you ever seen the same sql statement with different query results in PLSQL and SQLPLUS?

Today inPLSQL ofSQL Window A query was executed inselect * from t_user; search6 entry:

Later, to facilitate testing of additional data, sqlplus was opened and the same query statement was executed and the following accident occurred.

Only one row was queried, you read that right, same user, same sql statement, same time, different results in PL/SQL and SQLPLUS. So unhappy, I opened n more sqlplus windows and all the executions resulted in only one row. Another SQL Window was opened separately in PS/SQL, and after executing the same sql statement, the result was the same as the sqlplus query, also a single record.

So it occurred to me that the problem was mostly in the sql window of that PL/SQL query that got to 6 data. This finds the query select * from t_user executed inside it; Five additional records were previously inserted.

It turns out that, unlike SQL Server and MySQL, which I have used before, when operating oracle, after operations are performed on the data, these operations are only committed to memory and do not update the physical file, and finally if you need to update to the physical file, you need to execute the COMMIT command.

At this point, execute the commit command in this insert 5 data sql window and the data is actually inserted into the physical database file!

So, in oracle, whenever an operation is performed on the database that makes data change (add, delete, change, etc.), you need to execute the commit command to commit the update to the physical file of the database, otherwise all the previous operations done are in vain.

Comrades who know the EntityFramework may have thought of SaveChanges() at this point, yes! The reason is the same...

It is important to note that once a table has been After the operation, before the commit , this table will be in a locked state, and once it is locked, no other transaction can operate on it, as follows.

Open two sqlplus windows and perform the same update operation on the same table, but without committing.

Implement firstupdatet_user set user_name='userA' where user_id='user5' :

reimplementationupdate t_user set user_name='userB' where user_id='user5' :

The first action updates 1 row, and the subsequent action is dead, and does not say "1 row updated".

The reason for this is that the first operation did not perform a commit and already locked the table t_user (the legendary stopwatch ), so no other transaction is allowed to operate on this table until the first operation is COMMITTED.

(The query language followed by for update can also be used to lock the table being queried ~ e.g. select * from t_user for update; Once a query is executed, no other user is allowed to perform operations on this table other than the query until the transaction is committed. (If you want to verify, sqlplus is convenient and easy, try it yourself~~)

1、Scanning Lens NetEase School Programming Questions
2、Dry Synthesizing hyperrealistic faces with deconvolutional networks understanding how deep learning thinks
3、ContactManagerWebAPI Example 2 WebAPIRouting
4、DeepAn article on 3 example segmentation papers that dont require a Proposal
5、Three common cloud pitfalls that IT departments need to carefully avoid

    已推荐到看一看 和朋友分享想法
    最多200字,当前共 发送