Running UniData 7.1 and having difficulties of accessing virtual fields within
UniSQL.
We SQLized the UniData files using VSG. We then SELECT the table within
UniSQL.
There are good results returned from all the data fields, but, nothing
returned from any of the virtual fields.
Are there
Are you explicitly including the virtual fields in your select
statement? Are they in the @SELECT dictionary item?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Larry Chiang
Sent: Tuesday, January 08, 2008 10:59 AM
To: u2-users@listserver.u2ug.org
Yes. We started out by selecting a mixed of data and virtual fields. Once it
became apparent that no values returned from any of the virtual fileds, we
tried by selecting either just multiple or single virtual fields to no avail.
I'm not familiar with @SELECT dictionary item, but, they are
Are you using sql just from the sql prompt, or from ODBC? Any problems
with joins using ODBC?
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Larry Chiang
Sent: Tuesday, January 08, 2008 1:55 PM
To: u2-users@listserver.u2ug.org
Subject: RE: [U2] UniSQL
In the following query, a file is listed with two identical itypes,
save for field 2 spacing, as shown below. Fields 3 and 6 are all equal
in the query shown.
The difference is that there is no space between the and = . This
appears to yield wrong results, the bad one being shown as field 2
(all
I think it's to do with the compiler seeing the = symbol. I knew there
was a reason I always use spaces!!
Colin.
In the following query, a file is listed with two identical itypes,
save for field 2 spacing, as shown below. Fields 3 and 6 are all equal
in the query shown.
The difference is
What it is doing is evaluating as:
If @record is less than 3 is greater-than or equal to @record6 then 1
else -1
Or
In other words:
If 0 is greater-than or equal to 20071217:224240 then 1 else -1
-Original Message-
From: john reid [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 08,
I have to add that this is just the reason why I stress using spaces
between signs, variables, Boolean operators, and a liberal use of
parentheses.
-Original Message-
From: Jerry Banker [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 08, 2008 4:46 PM
To: u2-users@listserver.u2ug.org
I would think that honoring a reasonable order of operations when
parsing would resolve this. The extraction operator should certainly be
higher priority than comparison.
In fact, it works correctly in a BASIC program (UV 10.1.8). I compiled
and ran the following:
0001: XX=
0002: XX1=5
Have a _PH_ that is just full of crud and I cannot think of a convenient way
to automate the 'cleanup' from within UniData since there is nothing the key
to the _PH_ record that shows a 'date' -- the design cleverly stores the
User ID and ProcessID - both terribly non-useful for cleanup logic!!
Try DLIST. It's like VLIST, but for I-descriptors.
DLIST decompiles the I-descriptor into something that looks an awful lot
like the decompiled basic object that VLIST shows.
I put 2 I-descriptors called NICELY.SPACED and CRAMMED in DICT VOC
compiled them. Look how the 2 decompile into
11 matches
Mail list logo
