In REST APIs, each request must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. This is known as the stateless constraint of REST. Stateless does not mean there is no state; but the state is maintained on the client side instead of the server side.
However, in PowerBuilder, the transactional information must be maintained on the server side in order to provide context for subsequent transactions.
Due to this difference, the REST APIs in PowerServer have been adjusted to support the PowerBuilder transactions. When the REST APIs handle requests for Update, Insert, and Delete, a transaction will be started automatically, the transactional information will be stored on the server, and a default transaction timeout value is set. This will cause some differences to the Select Lock scripts. For example,
Original PowerScript:
//DOES NOT hold the lock Select max(1) Into :ll_test From table b with(updlock, ROWLOCK) Using sqlca; //in this case there is no open transaction and no locks. If you run in regular pb, there are locks.
Must be modified like below to work in PowerServer:
The "trick" is to hold the transaction open:
Update table A Set col1 = Set col1 where col1 = 1 USING SQLCA; //lock held Select max(1) Into :ll_test From table b with(updlock, ROWLOCK) Using sqlca; //now if you check the locks in sql server, you will see that they exist on table b (as well as table a)
