"QSELECT" builds a SELECTed list of values, which operation is also
possible with the "SELECT" statement, as noted. But the "QSELECT" statement have some options that implies a "Read" operation from the "&SAVEDLISTS&" file. It is assumed that, the "&SAVEDLISTS&" file being generally a Type 1 or 19 file, a Transaction cannot be ensured on this type of file. Subsequently, "QSELECT" is not permitted at all. If the equivalent of a "QSELECT" satement is to be performed in an Transactionnal application, the various steps to be executed would have to be explicitly programmed within the Transaction. In that sort of "workaround" programming, the programmer and applicative layer instead of the database engine are made responsible for application data consistency. An enhancement request could be raised toward IBM to allow in transactions those of the "QSELECT" syntaxes which are not involving the "&SAVEDLIST&" file. Though, I doubt the UniVerse Basic Run Machine has the ability to differentiate these syntaxes "on the fly", so the restriction was made to easily secure the transaction in all cases. Hervi BALESTRIERI Support Technique Avanci - IBM France ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
