Known issues with prowin32 as mstsc remoteapp (RDP)

Posted by cverbiest on 23-Dec-2015 04:02

Hi,

One of our customers insists on running our fat client prowin32 as a Microsoft RemoteApp (https://technet.microsoft.com/en-us/library/cc755055.aspx) .

We now encounter an issue that we don't see when we run the same code on the terminal server directly.

Are there known issues  with remote apps ? I searched the PKB but didn't find relevant info there.

An issue we encounter is error 17630 when deleting a temp-table record

SYSTEM ERROR: Index T-GRID3 in TGRID for recid <recid> partition <partition> could not be deleted. (17630)

The error is not-fatal, code execution continues but I cannot catch it.

code snippet : T-GRID is a temp-table holding ocx com-handles.

def temp-table T-GRID no-undo
    field PROG-HANDLE as widget-handle
    field TGRID-IDENT as char
    field TGRID-TITLE as char
    field TGRID-WIDGET as widget-handle /* rectangle */
    field CFGrid as widget-handle
    field chCFGrid as component-handle
    field TGRID-QUERY as handle
    field TGRID-FIELD-UNIEK as log init true 
    field TGRID-STATIC-COLUMN as log init true 
    /* grid housekeeping */
    field TGRID-NUM-ROWS as int
    field TGRID-NUM-COLUMNS as int
    field TGRID-ROWS-VAST as int
    field TGRID-COLUMNS-VAST as int
    /* trigger functionality housekeeping */
    field TGRID-LASTPOS as char
    field TGRID-LASTPOS-ENABLED as log
    /* tree view */
    field TREE-VIEW as log init false

    index T-GRID1 is unique primary TGRID-WIDGET
    index T-GRID2 is unique PROG-HANDLE TGRID-IDENT
    index T-GRID3 chCFGrid.

The error occurs in

PROCEDURE DestroyBuffer :

def param buffer BT-GRID for T-GRID.

delete object BT-GRID.CFGrid.

delete BT-GRID.

end procedure.

All Replies

Posted by Garry Hall on 23-Dec-2015 07:41

Given that this is a NO-UNDO temp-table, my guess at what is happening here is that there was some other error that caused the AVM to leave a block without doing the indexing. You defined the temp-table as NO-UNDO, meaning changes (even incomplete changes) don't get backed out in the event of undo.This is simple enough to reproduce:

DEF TEMP-TABLE tt1 NO-UNDO
    FIELD f1 AS CHAR
    FIELD f2 AS CHAR
    FIELD f3 AS CHAR
    INDEX ix1 IS UNIQUE PRIMARY f1
    INDEX ix2 IS UNIQUE f2
    INDEX ix3 f3.

DEFINE VARIABLE ictr AS INTEGER     NO-UNDO.
DEFINE VARIABLE ival AS INTEGER     NO-UNDO.

DO TRANSACTION:
    DO ictr = 1 TO 5:
        CREATE tt1.
        ASSIGN 
            tt1.f1 = FILL(CHR(64 + ictr),5)
            tt1.f2 = tt1.f1.
            tt1.f3 = tt1.f2.
            IF (ictr = 5) THEN
                ASSIGN
                tt1.f3 = "Error"
                ival = INT("error").
    END.
END.

FOR EACH tt1:
    DISPLAY tt1.
    DELETE tt1.
END.

To resolve this particular error, you need to identify what caused the transaction to terminate while updating the temp-table (specifically, updating the chCFGrid field). The cause of the termination is probably specific to RemoteApp. You might try 4GLTRACE:3,4GLTRANS:3 logging, although it is very verbose.

The alternative is to not declare the temp-table as NO-UNDO, and incur any performance penalties for it. Depending on how intensively this temp-table is used, that performance penalty might be inconsequential.

This thread is closed