> -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ken Wallis > Sent: Thursday, 19 May 2005 16:42 > To: [email protected] > Subject: RE: [U2] UV "PERFORM 'SELECT <filename> ...' " in > I-Type {Unclassified} > > > HENDERSON MIKE, MR wrote: > > > Folks, > > > > We have had a puzzling situation where a particular > > subprogram works differently when run from a test-harness > > from TCL, to when it is run as an I-Type subroutine. > > > > The sub-routine concerned is about three layers deep in > > the execution sequence:- > > > > Test-Harness does CALL A(<parameters>), A does CALL > > PROBLEM(<parameters>) I-Type says SUBR("X",<parameters>), > > and X does CALL A(<parameters>), A does CALL PROBLEM > >(<parameters>) > > > > When you LIST <file name> <I-Type name> the I-Type > > returns 'wrong' answers > > > > The programmer concerned eventually worked out that the > > problem was that, from the I-Type, a "PERFORM 'SELECT > > <filename> <with-condition>' " ALWAYS returned no records, > > whereas the same select works correctly from the test > > harness. No, the were no select lists active at the time! > > I'm sorry Mike, I'm having trouble with this statement. How > can there not be any select lists active when you are running > a retrieve statement? > Surely, internally, ALL such statements generate a temporary > select list and process it?
OK, as Wol also said, so there's an implicit select list active by virtue of the LIST statement. That provides a rationale for the anomaly. > > > The solution was to change the "PERFORM 'SELECT <filename> > > <with-condition>' " to a Basic "SELECT <filename>" and > > weed out the unwanted records in an internal loop. > > > > It may well be that it has always been this way, the > > I-Type is new. > > UV 10.0, Information flavour, Windows 2K3 > > > > Ideas, anyone? > > I think you just have to be *VERY* careful about using any > form of PERFORM/EXECUTE inside an I-type/virtual field. > First there are performance issues to think about, second, if > the thing you EXECUTE either generates or consumes select > lists then you need to be awful careful to make sure you > don't generate some unwanted side effects. The problem the programmer is trying to solve is to expose a data value for export to a data warehouse via a DTS package. This data value is not stored anywhere, it is always calculated. The calculation is very complicated and is represented by a mass of legacy code (tens of thousands of lines of UniBasic code in a nasty set of interlinking subprograms and include code files). Until now, this datum has only really ever been a display item on a screen, and on a couple of reports (UniBasic, not RetrieVe). > > I accept that sometimes there is really little option but to > implement something like this, but I'd certainly look hard at > all the alternatives I could before I sat down and cut code. > For example, on UniData, I'd far rather create a secondary > index on <filename> and do some READFWDs than either the > internal or external SELECTs you describe, is there a > UniVerse equivalent? I'd _love_ to do this kind of re-design, but it ain't gonna happen. Fortunately, the file being SELECTed has only got about half a dozen records in it, so performance of the SELECT is not a major issue. Thanks for the responses Mike > > Cheers, > > Ken > ------- > u2-users mailing list > [email protected] > To unsubscribe please visit http://listserver.u2ug.org/ > The information contained in this Internet Email message is intended for the addressee only and may contain privileged information, but not necessarily the official views or opinions of the New Zealand Defence Force. If you are not the intended recipient you must not use, disclose, copy or distribute this message or the information in it. If you have received this message in error, please Email or telephone the sender immediately. ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
