SQL UPDATE Statement Hangs Powerbuilder

Question

As the title says, I have a seemingly simple embedded SQL Update statement in my code that hangs Powerbuilder 12.5.

UPDATE COMMENTS SET comment_text = :strNewComment
WHERE ID = :lngID;

I've looked at the code in debug; all variables have valid values and execution stops exactly on that SQL statement.

The only 'theory' I have why this might be happening is that there might be a locking issue as the same data is open in a datawindow, but I'm not enough of a PB expert to know if it is.

A little background info around this scenario: A datawindow grid displays a list of comments. User selects a comment row, clicks an 'Edit' button and its click event fires. A modal window displays with the comment text in a textbox. User edits comment text, clicks OK button. Click event continues, running the above sql statement and then refreshing the datawindow with a Retrieve() call.

Answer 1

That's not how I would implement it... Send the updated text back to the calling procedure (lots of ways to do that...) and then do a SetItem() into the grid dw. From there, you can either call Update() on your grid dw immediately, or wait for more updates to be collected and update them all at once.

Embedded SQL updates that exactly mimic the functions of an existing datawindow are a poor design choice.

Answer 2

So I (accidentally) managed to find what was causing my problem.

I had inserted some test records via interactive SQL, then during dev tried to edit those records. The problem was...drum roll... I forgot to commit the manually inserted records! The records would be locked by interactive SQL until either commit/rollback or (in my case) close interactive SQL. I guess by fluke everytime I ran into this problem, it was with one of these manually inserted records.

So, nothing to see here. Just an SQL Anywhere newbie mistake. Thanks all for your help.

Answer 3

If you are dead-set on updating the database this way then I'd look at your datawindow that displays the list of records. Maybe embedded SQL tries to update the locked data I suppose that could cause hanging. A lock should show up on the database. Also consider select "for read only" if you are not updating via the datawindow.

I got the impression (from comments on the original question) you were able to perform the update but the change didn't persist in the database. Here are common solutions for that. It could be any of these and is probably one of them. The answer depends on which method you used for update.

• If you changed a column value in a datawindow via keyboard, or SetText than perform AcceptText on the datawindow control or tab out of the column to make sure the column value is accepted into the buffer for update. IE: dw_1.AcceptText()
• If you've done an accept text (error free) then perform the datawindow update like dw_1.Update() and make sure return code is good.
• Once your logical transaction is complete run an embedded SQL statement with: COMMIT; to commit the changes in dbms.
• If you are updating via embedded SQL, make sure you ALWAYS check SQLCA.SQLCODE after the command. It should be zero, or 100 for not found, negative for errors.
• If you are updating from datawindow, is the datawindow marked as "updateable"? It needs to be, when editing datawindow, use Rows--> Update Properties...

Answer 4

What datatype is the column comment_text in the COMMENTS table? How many characters are you expecting to support?

If you are updating large text or binary data from PowerBuilder embedded SQL, the way to do it is with an UPDATEBLOB statement.

Blob lBlob
bBlob = Blob(var_containing_large_string)
UPDATEBLOB COMMENTS
SET comment_text = :lBlob 
WHERE ID = :lngID 
USING trans_object ;

Please review the documentation of the setting BinTxtBlob and the SELECTBLOB and UPDATEBLOB statements at: http://infocenter.sybase.com The documentation is confusing because it states the column has to be of type "blob", but this includes the text datatype (as can be seen from the documentation of the BinTxtBlob setting).

Answer 5

I don't know what database you're using, but if it's taken a row lock this is the behavior I'd expect.

@NoazDad is an hugely experienced PowerBuilder person despite his current 71 points on SO. I'd take his advice (and that's how I'd do things, too).

Answer 6

it seems the table has been locked. There must be multiple possible ways that the table might locked. 1. Some other user is connected with the same database and doing some data manipulation in that table. 2. That table is not commited or rollback during previous execution by other instance.