UniCommand differences for UniData.

Question

I'm new to the world of UniObjects as I've been in .NET land since it debuted. After building a simple app to return the select list of a UniCommand statement I noticed that there are some major differences in how UniData and how UniObjects parses the UniCommand statments. From what I've found it looks like it is differences in the flavors of PICK used.

What I'm asking is for other UniObjects programmers (UniVerse or UniData) that know of the differences or know of commands that can be executed to list them here. I'm asking this because the documentation of what can and cannot be a command is very hard to find.

Here is an example: (both return the same results from the same source)

What we would enter into UniData: (parser error if given in UniCommand)

• SELECT COLORS = "BLU]"

What should be entered into UniObject's UniCommand:

• SELECT COLORS WITH @ID LIKE "BLU..."

Notice how UniData's wildcard is "]" (square bracket) where UniCommand is the "..." (elipsis). Also notice how UniData accepts the equality operator and how UniCommand uses the LIKE operator and WITH.

Also if anyone has a link to a document on all the commands available, they can post it here as well.

Answer 1

The problem is that your Unidata environment is set up to parse commands with the PICK parser, but the UniCommand object is executing Unidata's native parser. (The LIKE and ... syntax is from Unidata's native mode, which is modeled from Prime Information.)

I looked for a property on UniSession or UniCommand that would change the parser that's used for the Execute method, but didn't find one. However, the documentation of UniCommand says that it is equivalent to the EXECUTE basic statement. This, and a few UDT.OPTIONS commands, may open the door for a workaround that will let you use PICK command syntax even though UniObjects doesn't support it directly.

Unidata's EXECUTE command can take multiple commands, separated by @AMs, and will execute them one after another, returning only after all have been processed. (It's sort of like a mini-proc.) So, build your command with at least a "UDT.OPTIONS 2 ON" command in attribute 1, followed by any others that you may need, and finally your desired PICK command in the last attribute. Then send the whole bunch at once via your UniCommand object's Execute method.

---

The docs for UDT.OPTIONS 2 is as follows:

Determines the parser the system uses to interpret UniQuery commands.
    ON System uses the Pick® parser.
    OFF System uses the UniData parser.

There are several other UDT.OPTIONS related to PICK compatibility. Look in the docs, specifically udto.pdf, in the "Pick® Compatibility" section.

---

All that said, when I've use UniObjects, I've only used it to call basic subroutines, and handle everything else in server-side routines.

EDIT: C# code sample

UniSession s = UniObjects.OpenSession("machine", "user", "password", "/path/to/account", "udcs");
UniCommand c = s.CreateUniCommand();
c.Command = "UDT.OPTIONS 2 ON" + "\xfe" + "SELECT COLORS = \"BLU]\"";
c.Execute();

The "\xfe" is the attribute mark. (That's CHAR(254) in Pick-speak.) Hope this helps.

Answer 2

The differences you are describing are differences in ECLTYPE in UniData which is completely independent of UniObjects. If you set your UniData account's ECLTYPE to "U" it will accept the syntax:

SELECT COLORS WITH @ID LIKE "BLU..."

If you set the ECLTYPE to "P" it will accept the syntax:

SELECT COLORS = "BLU]"

The UniObjects for .NET documentation states:

"On UniData systems, ECLTYPE U is best. You may encounter variations with other ECLTYPE or UDT.OPTIONS settings."

It's not clear to me from the documentation whether UniCommands are invariably executed using ECLTYPE "U" or whether there is a parameter to let you configure the parser type. You could try executing an ECLTYPE "P" command from your UniObjects session and then see whether subsequent UniCommands with "P" syntax are parsed as such.