Fw: [U2] [UV] QSELECT in transaction
Hi All, Just needed to clear up where we are with QSELECT question for everyone on the list. We've done some researching on the issue, as it is also a currently active support case asked by a customer in South Africa. Previous comments about the interaction with the SAVEDLISTS file would be incorrect, after all SAVE.LIST is also allowed in a transaction. We are unsure at this time if the omission of QSELECT was by design or an oversight. We have been able to get QSELECT to work within a transaction by a simple change, however we are still looking to see if this change has any unwanted interactions or implications in other areas of the transaction or UniVerse. The good news is that, if the tests go well then you will be able to make the same change for yourselves without having to upgrade UniVerse. Regards, Jonathan Smith IBM Certified Solutions Expert Advanced Support Engineer - U2 Advanced Technical Support IBM Data Management Solutions Support Phone 0800 773 771 Support mailto:[EMAIL PROTECTED] http://www.ibm.com/software/data/u2/support - Open, Query, Update, Search - Online! DISCLAIMER:This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please delete it and notify the sender immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] [UV] QSELECT in transaction
You can try this yourself by adding an 'H' to field 4 of the VOC item for QSELECT is suspect. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jonathan D Smith Sent: Thursday, 3 August 2006 8:01 p.m. To: u2-users@listserver.u2ug.org Subject: Fw: [U2] [UV] QSELECT in transaction Hi All, Just needed to clear up where we are with QSELECT question for everyone on the list. We've done some researching on the issue, as it is also a currently active support case asked by a customer in South Africa. Previous comments about the interaction with the SAVEDLISTS file would be incorrect, after all SAVE.LIST is also allowed in a transaction. We are unsure at this time if the omission of QSELECT was by design or an oversight. We have been able to get QSELECT to work within a transaction by a simple change, however we are still looking to see if this change has any unwanted interactions or implications in other areas of the transaction or UniVerse. The good news is that, if the tests go well then you will be able to make the same change for yourselves without having to upgrade UniVerse. Regards, Jonathan Smith IBM Certified Solutions Expert Advanced Support Engineer - U2 Advanced Technical Support IBM Data Management Solutions Support Phone 0800 773 771 Support mailto:[EMAIL PROTECTED] http://www.ibm.com/software/data/u2/support - Open, Query, Update, Search - Online! DISCLAIMER:This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please delete it and notify the sender immediately. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Fw: [U2] [UV] QSELECT in transaction
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/
Re: [U2] [UV] QSELECT in transaction
Assuming we're talking about uniVerse (and not uniData): PERFORM is a different command. EXECUTE creates it's own execution environment, where PERFORM does not. This means that with PERFORM you can do a series of SELECT statements in the following way: PERFORM SELECT ANIMAL WITH SPECIES = 'Lion' IF (@SYSTEM.RETURN.CODE 0) THEN PERFORM SELECT ANIMAL WITH NAME = 'Simba' END At the end of this BASIC code your active select list contains all records matching the select statements as if you entered them on the command line. With an EXECUTE this does not work. To achieve the same result with an EXECUTE you'd have to do the following: EXECUTE SELECT ANIMAL WITH SPECIES = 'Lion' AND NAME = 'Simba' SETTING nrOfRecords Depending on your selection you'd have to chose what is best. If you're using complicated I-descriptors (that can make selecting on them slow), I'd use a series of PERFORM statements instead of an EXECUTE. If you're using @USER0 through @USER4 in your I-descriptors, those won't be propagated to the statements you run with an EXECUTE statement so you'd have to use a (series of) PERFORM statements for those. As for the original question in this thread, I'm afraid you can't use a QSELECT inside a transaction on uniVerse. I'd like to add that doing SELECT / SSELECT statements inside database transactions on uniVerse can sometimes cause database corruption (we once had this happen to one of our customers' accounts), so I would advise against that. Regards, Mark Cornelissen http://www.innovate-it.com On Jul 27, 2006, at 04:44, Dave R wrote: Preform is an older version and sometime you get different results? D Raven [EMAIL PROTECTED] cell (949)2282224 e Fax (815)4259364 P.O. Box 17811, Irvine CA 92623-7811 -- Ray Wurlod [EMAIL PROTECTED] wrote: Have you tried PERFORM rather than EXECUTE? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] [UV] QSELECT in transaction
Whats slightly confusing / inconsistent is that an EXECUTE with SELECT / SSELECT is catered for inside a transaction but not QSELECT? Why allow / cater for one and not the other? -Brian. Important Notice: This email is subject to important restrictions, qualifications and disclaimers (the Disclaimer) that must be accessed and read at the following address or by copying and pasting the following address into your Internet browser's address bar: http://www.frstia.co.za/Disclaimer.asp The Disclaimer is deemed to form part of the content of this email in terms of Section 11 of the Electronic Communications and Transactions Act, 25 of 2002. If you cannot access the Disclaimer, please obtain a copy thereof from us by sending an email to mailto:[EMAIL PROTECTED] FirstRand STI Admin (Pty) Ltd is an Authorised Financial Services Provider --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
[U2] [UV] QSELECT in transaction
Hi, is there a way to allow an EXECUTE QSELECT... inside a transaction in a basic program. The HELP BASIC EXECUTE specifies a few verbs that are allowed inside transaction : if a SELECT / SSELECT is allowed, cant a QSELECT be allowed aswell? Or might I be missing something? Any ways to overcome this? Thanks. Regards, Brian. +--- ---+ |The EXECUTE statement fails and the program terminates with a | |run-time error message if: | | | |o dynamic.array or expression in the IN clause evaluates to the | | null value. | | | |o The command expression evaluates to the null value. | | | |Although you cannot use the EXECUTE statement within a | |transaction to execute most UniVerse commands and SQL | |statements, you can use EXECUTE to execute the following | |UniVerse commands and SQL statements within a transaction: | | | | CHECK.SUM INSERT SEARCH SSELECT | | COUNT LIST SELECT (RetrieVe) STAT | | DELETE (SQL) LIST.ITEMSELECT (SQL)SUM | | DISPLAYLIST.LABEL SORTUPDATE | | ESEARCHRUN SORT.ITEM | | GET.LIST SAVE.LISTSORT.LABEL | | | | More End Help List Commands | +---+ Page Up/Page Down +--+ Verb QSELECT illegal when a transaction is active. Rolling back uncommitted transactions begun within this execution environment. Important Notice: This email is subject to important restrictions, qualifications and disclaimers (the Disclaimer) that must be accessed and read at the following address or by copying and pasting the following address into your Internet browser's address bar: http://www.frstia.co.za/Disclaimer.asp The Disclaimer is deemed to form part of the content of this email in terms of Section 11 of the Electronic Communications and Transactions Act, 25 of 2002. If you cannot access the Disclaimer, please obtain a copy thereof from us by sending an email to mailto:[EMAIL PROTECTED] FirstRand STI Admin (Pty) Ltd is an Authorised Financial Services Provider --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] QSELECT in transaction
is there a way to allow an EXECUTE QSELECT... inside a transaction in a basic program. The HELP BASIC EXECUTE specifies a few verbs that are allowed inside transaction : Have you tried: SELECT FILE SAVING FIELD.NAME ? For example: SELECT CUSTOMERS SAVING KEY.ADR ? It should be the equivalent of: QSELECT CUSTOMERS SAVING (field #) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] QSELECT in transaction
Have you tried PERFORM rather than EXECUTE? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] [UV] QSELECT in transaction
Preform is an older version and sometime you get different results? D Raven [EMAIL PROTECTED] cell (949)2282224 e Fax (815)4259364 P.O. Box 17811, Irvine CA 92623-7811 -- Ray Wurlod [EMAIL PROTECTED] wrote: Have you tried PERFORM rather than EXECUTE? --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
