So I am still dabbling with ColdFusion. It is satisfying to be able to connect
Flex - CF - UniVerse and see data.
When data appears in say two tables, the traditional CF way to grab the data is
with al SQL INNER JOIN statement.
It seems like all that I can do with CF and UniVerse is something
Bill
I don't know ColdFusion, so I don't know how you're connecting CF to
Universe or what CF is doing - but UniVerse SQL *definitely* supports joins.
And if you can't get CF to build it, if you can get it to call stored
procedures you can also lovingly hand craft your UniVerse SQL grin and
Brian:
0. Thanks for writing and for the example code.
1. I see that JOINS appear in my older copy of the Rocket manual. Thus...
SELECT * FROM LATES,INVOICE WHERE LATES.PACKSLIP = INVOICE.ID
SQL+
PACKSLIPLATE_CODEASSIGNED_BYDATE..TIME..ORDER..
254889 C.FC
We've been using the following command to select a name regardless of how it's
capitalized:
SELECT CLIENT WITH NAME CONV MCU = BRUCE]
However, after I indexed the field NAME on the CLIENT table the same command
only returns
the values that match the case-sensitive. In other words after we
Could you create another dict item called NAME.UPCASE and put the MCU in
that definition?
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Chris Austin
Sent: Tuesday, July 26, 2011 9:25 AM
To:
I'm not exactly following you. Would this dict item called NAME.UPCASE, would
that be a new field to test this or woudl that be a specific field
used to do the conversion? What would the dictionary look like.
Chris
From: bl...@shaklee.com
To: u2-users@listserver.u2ug.org
Date: Tue, 26 Jul
We are using Unidata and this is a dict for Country:
CNTRY:
D
4
MCU
Cntry
6L
M
You could do the same change to the NAME definition but I was suggesting
that if you didn't want to or couldn't do that then another definition could
be created that forced the name to be upper-case.
I changed the DICT entry for field NAME on the CLIENT table to the following:
NAME
0001 D
0002 5
0003 MCU
0004 Name
0005 25L
0006 S
0007
0008 CHARACTER,25
But it still doesn't seem to work in regards to the case-sensitive.
Chris
From: bl...@shaklee.com
To:
Did you create the index for the field like John Thompson suggested?
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Chris Austin
Sent: Tuesday, July 26, 2011 10:37 AM
To: u2-users@listserver.u2ug.org
Subject: Re:
I could be wrong, but if there is an existing index on the dictionary 'NAME'
you will need to rebuild the index after you change it for it to take affect
with the index.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On
Basically what I tried was editing the existing DICT entry for the field NAME,
by placing the value MCU in line #3. I don't think this is what
John referred to though. Should I keep the field NAME like it is now (without
the MCU) and create another DICT entry?
Chris
From: bl...@shaklee.com
That is up to you. Try rebuilding the index on NAME and see what that gets
you.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org
[mailto:u2-users-boun...@listserver.u2ug.org] On Behalf Of Chris Austin
Sent: Tuesday, July 26, 2011 10:51 AM
To: u2-users@listserver.u2ug.org
Could you create another dict item called NAME.UPCASE and put the MCU in that
definition?
I guess I'm not sure what the above dictionary entry would look like. Would
this be a dictionary entry
that's just used to do the conversion on NAME?
Currently this is what I have for field name:
universe or unidata? what flavor?
I don't see how this would have worked in the first place? When you use a query
with literal comparisons, the literal is compared against the pre-converted
value. If the attribute has a reversible conversion then your literal will be
reverse-converted first,
Assuming you have a DICT item called NAME.
Assuming this is not a live system that queries are happening :)
Then you changed the conversion on it to MCU.
Just do the following:
DELETE.INDEX filename NAME
CREATE.INDEX filename NAME
BUILD.INDEX filename NAME
If you wanted to create another DICT
Ed might be right... I was just trying to help you understand what I think
to be true:
Usually if you change a Dictionary that an index is built on, you have to
rebuild the index for that dictionary. This is especially true on any
I-type dictionary.
On Tue, Jul 26, 2011 at 2:09 PM, Ed Clark
This is UniVerse 10.x (newer flavor). This command has been working flawless
until we indexed that field. If I remove the index it works using the CONV MCU,
perhaps
maybe you cannot use the CONV MCU on an indexed field?
I tried to delete the index, rebuild it (with the MCU conv), and I ran
Chris,
The problem is that your index was built case sensitive and now you're requests
are upper case only so it will only get upper case indexes. You need to rebuild
the index with the dictionary item that does the MCU, that way all of your
indexes are upper case.
Hth,
Curt Stewart
Chris
Chris,
I would create a new i-descriptor dictionary called UNAME.
The formula would do the uppercase logic like: OCONV(NAME, MCU) or
UPCASE(NAME).
Then build your index on UNAME.
And use UNAME in your SELECT statements for a filter and display NAME for
output.
David A. Green
(480) 813-1725
DAG
Curt,
I deleted the index completely (DELETE.INDEX CLIENT NAME).
Then I created the DICT for NAME:
NAME
0001 D
0002 5
0003 MCU
0004 Name
0005 25L
0006 S
0007
0008 CHARACTER,25
Then I created the INDEX for NAME (CREATE.INDEX CLIENT NAME)
Finally I built the indices for NAME (BUILD.INDEX
universe is doing something fundamentally weird with this. The select works
differently if you use a wildcard or have an index.
Create a file with some multi-case data:
0001 EXECUTE 'CREATE-FILE TESTFILE 1 1'
0002 OPEN 'TESTFILE' TO FP ELSE ABORT
0003 CLEARFILE FP
0004 OPEN 'DICT','TESTFILE' TO
It looks like you are doing it in the right order...
I wonder if that character limit thing is messing you up in attribute 8?
(just a shot in the dark)
Also, what flavor of Universe account are you running?
You can find this out by:
CT VOC cataloged.program.name
Look in attribute 6 and it
also, if that doesn't worktry it this way as well
NAME.UP
0001 I
0002 UPCASE(NAME)
0003
0004 Name
0005 25L
0006 S
Then do a CREATE and BUILD index on NAME.UP
and make your QUERY against NAME.UP, instead of NAME
You can have as many DICT items as you want point to the same attribute number
Ah yes... welcome to the Universe query processor. Just try working with
exploded sorts with PICK type dictionaires- then you will start to cry...
Chris is this in a BASIC program that this select is happening?
Is it using User Input?
If so, you can save yourself a TON of trouble, by just doing
Ed,
You're right on the money here ( I believe). The difference seems to be with
the wildcards:
Before indexing the field NAME I could use the following command with no
trouble:
SELECT CLIENT WITH NAME CONV MCU = BRUCE]
After I indexed the field NAME I can ONLY use the following command to
Probably a bug. Should be reported to rocket... Although I have no
idea how to do that. I'm sure someone on the list does though.
On 7/26/11, Chris Austin cjausti...@hotmail.com wrote:
Ed,
You're right on the money here ( I believe). The difference seems to be with
the wildcards:
Before
I agree, this has to be a bug since the returned data all starts with a B such
as the following:
Client.. Name.
C438333-8BRUCE
C593410 BRUCE
C593410O BRUCE
C595181 BRUCE
C595181O BRUCE
C595238 BRUCE
C595238O
Just curious and maybe I missed it...
Has anyone tried LIKE and ... instead?
I wouldn't think it would be any different, but then I would have thought the
] select would have worked.
Robert Porter, MCSE, CCNA, ZCE, OCP-Java
Lead Sr. Programmer / Analyst
Laboratory Information Services
I've never used either of those commands, if you can give me an example using
each on a select I would be more than happy to test it out:
SELECT CLIENT WITH NAME = BRUCE (use this select to modify with the 2
commands)
Also, We're using this with a dojo filteringSelect + QueryReadStore.
I think your running in PICK mode, and I know that LIKE works in PICK flavor as
well.
LIKE is the equivilent to [ and ]
SELECT FILE WITH NAME = [TEST
SELECT FILE WITH NAME LIKE ...TEST
SELECT FILE WITH NAME = TEST]
SELECT FILE WITH NAME LIKE TEST...
SELECT FILE WITH NAME = [TEST]
SELECT FILE
It's actually all just part of the SELECT
SELECT FILENAME WITH FIELD LIKE (something)...
(similar to = something ])
SELECT FILENAME WITH FIELD LIKE ...(something)
[(something)
SELECT FILENAME WITH FIELD LIKE ...(something)...
[(something)]
Chris Austin cjausti...@hotmail.com
George,
I just rebuilt the indices on the CLINE table, then tried the LIKE using the
'...' as a wildcard, so I tried:
SELECT CLIENT WITH NAME LIKE BRUCE...
and unfortunately that worked the exact same way as the [] wildcards, returning
1 result.
The approach I'm going to use is the one you
I'd only index NAME if you are going to use it in any SELECTs that you want
optimized. We can't really answer that question.
-Original Message-
From: u2-users-boun...@listserver.u2ug.org [mailto:u2-users-
boun...@listserver.u2ug.org] On Behalf Of Chris Austin
Sent: Tuesday, July 26,
I believe a long time Universe support person once told me
that secondary indices are essentially just Type 25 files, or B-Tree files.
So when you build one, its essentially taking output from the query
processor and squirreling that away in a Type 25 file at the OS level.
So for example, I have
34 matches
Mail list logo
