Wildcard

Kathleen,

The parsing of the SELECT verb is determined by the setting of the ECLTYPE

ECLTYPE P will expect SELECT VOC WITH @ID = "[KH]"

ECLTYPE U will expect SELECT VOC WITH @ID LIKE "...KH..."

The extra little trick UniData has is ... at ECL if you enter the command in lower case it is always parsed as ECLTYPE U, so even if ECLTYPE is P, select VOC WITH @ID LIKE "...KH..." will work

You can also utilize the same trick in your programs by using UDTEXECUTE over EXECUTE / PERFORM, the UDTEXECUTE always forces ECLTYPE U.

Thank you Jonathon - Looks like that is UDT.OPTIONS 2. If I set this to do 'p' style and all the programs here are set as 'u' style - will this cause me heartache? Or can I easily keep my searches separate from my program executes?

Kathleen,

You will be probally find UDT.OPTIONS 2 is ON because somewhere in the login paragraph ECLTYPE P has been done rather than UDT.OPTIONS 2 ON.

If the programs have all been compiled with BASICTYPE U then you will not be able to use Pick Type searches in those programs as BASICTYPE U will force all the EXECUTE / PERFORM statements to go through the default UniData parser, setting the ECLTYPE has no impact on the BASICTYPE.

The U option for ECLTYPE and BASICTYPE is the default in UniData, in general the workarounds I mentioned in my previous message detailed how to force U when type P was being used do not apply in this situation.

If I understand what you are wanting to do, is to use ECLTYPE P at a site that is using ECLTYPE U and BASICTYPE U and not the other way around.

If that is correct, then you can set ECLTYPE to P for the duration of your session and you will be able to use a UniQuery in pick format at ECL. If the programs you are running have been compiled in BASICTYPE U, the setting of ECLTYPE P does not affect them (so my comment above). It will cause a problem if those programs run paragraphs or procs though.

Given that the site you are now at seems to have adopted the UniData parser, I would suggest you embrace the UniData parser and Basictype setting that are in place, because although for the duration of your session you set ECLTYPE to P you are going to have maintain programs using the UniData parser, so will need to know how to use that standard. Also if you go down a different route to everyone else you are only going to confuse everyone else.

Final word of warning if you do decide you will set ECLTYPE to P for your session, while you are working, only set this at ECL once you have logged in, do not change it in the login paragraph otherwise you change it for everyone. The ECLTYPE P / U setting does not just affect Query commands, if affects other commands such as COPY and some options of the commands are not available in type P, so please do not go and change something that will confuse or break something for anyone else.

I do not understand your question about keeping your searches seperate from your program executes.

Regards,

Hi Kathleen, 

A side note on the UniBasic code - if your programs are being compiled as type 'U', there are some syntax differences you have to watch out for, such as the LOCATE statement.  

Thanks Mark and Jonathon - I will take your advice and just get used to the new syntax ;)

I just make it easy on myself and create a paragraph called LID.

:ED VOC LID

PA                                                                        

SORT <<A,I2,Filename>> WITH @ID LIKE "...<<A,I3,String>>..." ID.ONLY <<C4,Arg1>> <<C5,Arg2>> <<C6,Arg3>> <<C7,Arg4>> <<C8,Arg5>> <<C9,Arg6>>

Then at TCL all you need to do is:

LID VOC RPT

To find all VOC entries with RPT in the name.

or

LID CUSTOMERS A...Z

will find all customers with and A and then a Z somewhere in the name.

etc.