There is only one query engine in UniVerse.  There are two query parsers, one for 
RetrieVe and one for SQL, developed independently (15 or so years apart) but both, as 
far as I am aware, based on yacc.  Leroy might like to chip in on this one.  On this 
basis I would be loath to agree that the "SQL Interface is Faster than any other 
Interface within UV".  A well-constructed query *should* generate the same parse tree.

UniVerse's history began as a quest for Prime INFORMATION's market share. Therefore 
the wildcard characters from Prime INFORMATION ("..." and "0X") are used with the LIKE 
keyword in RetrieVe if the account flavor is Prime-based; that is, IDEAL, PIOPEN or 
LIST filename WITH lastname LIKE "...SMITH..."
In these flavors, "wildcard" is actually a particular example of a more general 
concept called pattern matching. Patterns can include explicit or "any" numbers of 
alphabetic, numeric and "don't care" character classes.

Later, UniVerse went after some of Pick's market share, and therefore accommodated 
Pick's style of wildcard character ("[" for leading wildcard and "]" for trailing 
wildcard).  Therefore these wildcard characters are seen used in RetrieVe in 
Pick-style accounts; that is, PICK, REALITY and IN2 flavors. 
Interestingly (or not) the wildcard operators work with the "=" operator (rather than 
LIKE) in these accounts.
LIST filename WITH lastname = "[SMITH]"

Prime-style wildcards, in phrases commencing with WITH or WHEN, work in all account 

UniVerse SQL complies with ODBC 2.0 (there's a compliance statement for the exact 
levels for grammar and API in the UniVerse SQL manual).  Here the "%" character is a 
multi-character-matching wildcard, and the "_" character is a 
single-character-matching wildcard.  [I know you know that, Joe, but other readers may 

SQL is explicit about which quote characters are used where, RetrieVe is more 
laissez-faire.  This may add a few microseconds to the parse phase.

Finally, there are some things that SQL can do that RetrieVe can not do, and there are 
some things that RetrieVe can do that SQL cannot do.  There are some things that 
UniVerse SQL can do that standard SQL cannot do (even that some vendor's extensions 
cannot do, such as detail and summary lines in the same report - BREAK ON rather than 
GROUP BY). So I would counsel everyone who's interested to learn the full capabilites 
of all the bits and pieces, so that you can always choose the best tool for any 
particular job.

I suspect that there is a large body of U2 practitioners out there (maybe Joe's 
colleagues among them) who are "living in the past" to some extent, who have not kept 
up with new and different (and sometimes more performant) ways of doing things.  As a 
quick f'r instance, if I were set the task of selecting records based on an indexed 
field (column) from a UniVerse BASIC program, I'd use SELECTINDEX to process the index 
directly, rather than use a query to generate the Select List.  But SELECTINDEX hasn't 
been in the product since version 1 (I think it only came in in version 7.3 or 
thereabouts, but even that's quite a few years ago).  Alas, there is a LOT of legacy 
code dating from the early days of UniVerse (and even earlier, if it was migrated from 
Prime INFORMATION or Pick) that no-one's ever bothered to examine with a view to 
implementing more efficient processing.  One can understand the "if it's not broken 
don't fix it" mentality but to these folks employ a person carry
 ing a red flag to precede their automobile, as used to be required until the law was 

----- Original Message -----
From: "Joe Eugene" <[EMAIL PROTECTED]>
Date: Wed, 31 Mar 2004 16:37:54 -0500
To: "U2 Users Discussion List" <[EMAIL PROTECTED]>
Subject: RE: Modern Universe (TESTING)

> Ray,
> I see you are doing a few things here, am not quite sure i understand.
> The only way i have OUR UV Programmers using BASIC/PICK do this
> is like
> a bit OFF)
> Something like the above produces a CASE-INSENSITIVE Search and returns
> all the below
> Sara
> sarra
> saRraA etc.
> The UPCASE and LOWCASE only Returns those results right?
> So in your Experience, would you say SQL Interface is Faster than
> any other Interface within UV?
> Thanks,
> Joe Eugene
> >-----Original Message-----
> >Behalf Of Ray Wurlod
> >Sent: Wednesday, March 31, 2004 3:57 PM
> >To: U2 Users Discussion List
> >Subject: RE: Modern Universe (TESTING)
> >
> >
> >On this basis here are the RetrieVe equivalents for my earlier
> >post.  The main difference is that there's more than one verb (for
> >different query result formats) and the selection criterion begins
> >with the keyword WITH rather than WHERE.  And the pattern matching
> >specifiers are different (for example ... rather than % for
> >multi-character wildcard).
> >
> >
> >where verb can be any of:
> >LIST          SORT            columnar report
> >SELECT        SSELECT         Select List
> >LIST.ITEM     SORT.ITEM       raw format
> >LIST.LABEL    SORT.LABEL      mailing labels
> >REFORMAT      SREFORMAT       target is second file/table
> >SUM                           not really relevant for NAME
> >
> >HTH
> >----- Original Message -----
> >From: "Joe Eugene" <[EMAIL PROTECTED]>
> >Date: Wed, 31 Mar 2004 15:33:20 -0500
> >To: "U2 Users Discussion List" <[EMAIL PROTECTED]>
> >Subject: RE: Modern Universe (TESTING)
> >
> >> Tim,
> >>
> >> My apologies... Yes, i know UV has a SQL Interface but i didnt think
> >> many UV Programmers used this Interface...
> >>
> >> As a matter of Fact, i like the UV SQL Interface. I have a PE
> >Edition of UV
> >> on all my machines and i have only used the SQL Interface within UV.
> >>
> >> In our UV Shop, UV Guys are NOT supposed to use this SQL Interface
> >> as they claim its very slow than using the Native "SELECT WITH ....."
> >>
> >> I have read the UV Manual that reflects RDBMS, this manual explains you
> >> can setup Tables Exactly like any RDBMS using Data Types
> >(Varchar, char,  Int etc)
> >>
> >> All the the testing i have done does NOT involve using the SQL
> >Interface in UV,
> >> Our UV Shop uses FILE Types, NOT RDBMS Tables and we use
> >> PICK/BASIC/REDBACK to Interfact with these FILES.
> >>
> >> Perhaps the problem might be our UV Shop using PICK/BASIC...
> >> Maybe the SQL Interface on UV is much faster. I dont know.
> >>
> >> Thanks,
> >> Joe Eugene
> >>
> >>
> >>
> >> ________________________________
> >>
> >> From: [EMAIL PROTECTED] on behalf of Timothy Snyder
> >> Sent: Wed 3/31/2004 3:12 PM
> >> To: U2 Users Discussion List
> >> Subject: RE: Modern Universe (TESTING)
> >>
> >>
> >>
> >>
> >> Joe Eugene wrote on 03/31/2004 02:59:29 PM:
> >>
> >> > Please post your PICK/BASIC and SQL Query.. so we i can learn
> >> > the magic you did on the PICK Side.
> >>
> >> Joe,
> >>
> >> Unless I'm missing something, Sara used the SQL statement against the
> >> UniVerse database.  Perhaps you weren't aware that UniVerse supports SQL
> >> statements to query the database.  I don't think she used any "magic".
> >> Therefore, in her original post, she provided all the
> >information you need
> >> to do a comparison.
> >>
> >> Also, you keep referencing PICK/BASIC.  BASIC is the programming
> >language,
> >> not the query language.  There is also a native query language,
> >but that's
> >> only one of many ways to access the database.
> >>
> >> I hope this helps to clarify your expectations.
> >>
> >>
> >> Tim Snyder
> >> IBM Data Management Solutions
> >> Consulting I/T Specialist , U2 Professional Services
> >>
> >> Office (717) 545-6403  (rolls to cell phone)
> >> --
> >> u2-users mailing list
> >>
> >>
> >>
> >
> >>
> >> --
> >> u2-users mailing list
> >>
> >
> >--
> >u2-users mailing list
> >
> -- 
> u2-users mailing list

u2-users mailing list

Reply via email to