Flush forces the write of buffered records, even though the buffer is not full yet.

Syntax

   Flush [ classe ]

Setups

Element

Description

Restrictions

class

Table abbreviation, by default the default table

The table must be opened by a File order.

Examples

Call DEBTRANS From GLOCK
adxwrb=10 : # Value
$TR1
[V]GOK = 1 : Trbegin [SOH] : # Transaction start
# Loop on both tables (each possessing a buffer)
For nolign=1 to [M]LINNBR
  [F:SOP]=[M] : Writeb [SOP] : # Write with buffer
  If [S]fstat<>0
    If adxwrb=1 :  Call FSTA(“SOP”) From GLOCK : Endif : The erroneous line is known
    Break : # error on one of the lines
  Endif
  [F:SOQ]=[M] : Writeb [SOQ] : # Write with buffer
  If [S]fstat<>0
    If adxwrb=1 :  Call FSTA(“SOP”) From GLOCK : Endif : The erroneous line is known
    Break : # error on one of the lines
  Endif
Next nolign
If [S]fstat<>0 : Goto ROL_TR1 : Endif : # Error on one of the lines

# Make sure all the lines [SOP] and [SOQ] have been written
If adxwrb>1
  Flush [SOP] : If [S]fstat<>0 : Goto ROL_TR1 : Endif
  Flush [SOQ] : If [S]fstat<>0 : Goto ROL_TR1 : Endif
Endif

# Write header
[F:SOH]=[M]
Write [SOH] : # no stacking here, a single one is written
If [S]fstat<>0
  Call FSTA(“SOH”) From GLOCK : Goto ROL_TR1 : # Error on header
Endif
Commit
Return : # Everything is OK

# In case of error, if you were in grouped mode, proceed again to identify the erroneous line
$ROL_TR_1
Rollback
If adxwrb>1 : adxwrb=1 : Goto TR1
GOK=0
Return

Description

Flush is used to empty the buffer of the records to write, for the table specified as parameter. These records have been buffered by instruction Writeb.

Instruction Flush triggers the write of lines that would not have been written and would remain in the buffer. Caution, it is imperative to carry out a Flush before carrying out the Commit! In fact, not only the Commit does not "flush" the lines sent by Writeb, but it generates an error if some lines remain in the writing buffer, unsent. Therefore, it is important to carry out a Flush to make sure that the lines have been written and, in all cases, before carrying out the final Commit.

Instruction Rollback takes into account, of course, all the writing, whether it is carried out via Writeb orWrite.

Flush updates the variable fstat to indicate how the write has been carried out, but the erroneous line is not identified. A solution to identify the erroneous line is to position [S]adxwrb after the rollback and to try again the update transaction without buffering. Thus, the error will occur on the pending line.

fstat

Code

Ecr.

Explanation

0

Yes

Writing has been carried out correctly.

1

ERLOCK

No

Locked table.

3

ERDUPCL

No

Trying to create a duplicate key.

The example, hereafter, shows a case where cascade creations are carried out. This is the most interesting case as far as optimizing is concerned. The purpose of the code written on the label ROL_TR_1 is not to start the transaction over again with the hope that it could succeed (if there were duplicate keys, they will remain, except if they are deleted by another user); the purpose is to simply relaunch the transaction, line by line, so as to know how to identify the exact line where the error occurs.

The modification of variable adxwrb leads to an error if the lines are still in writing buffers. Therefore it is imperative to carry out the Flush or the Rollback before modifying it.

Associated keywords

ADXWRB - WRITEB - FOR - ADXFTL - FSTAT