Select statement

1 view
Skip to first unread message

Rick

unread,
Jul 17, 2008, 9:24:18 PM7/17/08
to InterSystems: MV Community
Guys,

I have a select statement that is not working. The emulation is set
to "cemu PICK". The select statement is as follows:

SSELECT DBCLIENT WITH DBC.CLIENT.NAME_s ="[AP]" BY DBC.CLIENT.CODE

This statement returns no items when it should return 15.

What am I doing wrong?

Thanks,

Rick

Jim Idle

unread,
Jul 17, 2008, 10:31:42 PM7/17/08
to InterSy...@googlegroups.com
Not reading the posting guidelines and posting enough information? ;-)

Seriously though, you need to show what DBC.CKIENT.NAME_s actually is. Many times this comes down to the fact that you have conversions and correlatives the wrong way around and happen to get away with it on other systems because invalid conversion codes return the incoming string. So you might thing you are comparing upper case AP but in fact you are not and so on. You have 30 seconds to post the dictionary entry or this email will self destruct and fire you.

It is possible that there is a bug but that one seems too simple for that. Also You can try the (Y option and the (Z or ZH option to view the execution plan and COS code (which gives you the SQL statement it uses for instance.

PICK gives you the equivalent of UniVerse PICK emulation, perhaps you want R83?

Jim

Ed Clark

unread,
Jul 18, 2008, 8:21:59 AM7/18/08
to InterSy...@googlegroups.com

First, make sure you are actually using PICK emulation by running the
CEMU command. Once you set the CEMU in an account, it stays until you
change it, but new accounts are created by default with CACHE emulation.
If the command still doesn't work, then we need to see the dictionary
entries for DBC.CLIENT_s and DBC.CLIENT.CODE

Rick

unread,
Jul 18, 2008, 1:56:51 PM7/18/08
to InterSystems: MV Community
Jim,

You are correct. By default, when we create a conversion we place it
in attr<7> (ie, MCU). This works perfectly in all other
implementations except Cache. I have asked support if this was going
to be changed a while ago but completely forgot about it. When I went
to port our newest version to Cache, I didn't recall this at all until
you reminded me.

Sorry for the brain fart but since we support so many MV
implementations, its hard to keep them all straight.

Thanks for your help and plead for my job ;-),

Rick

Jim Idle

unread,
Jul 18, 2008, 2:35:06 PM7/18/08
to InterSy...@googlegroups.com
On Fri, 2008-07-18 at 10:56 -0700, Rick wrote:
Jim,

You are correct.
:-)


 By default, when we create a conversion we place it
in attr<7> (ie, MCU).  This works perfectly in all other
implementations except Cache.  I have asked support if this was going
to be changed a while ago but completely forgot about it.  When I went
to port our newest version to Cache, I didn't recall this at all until
you reminded me.

Yeah - though it doesn't actually work perfectly on other releases, it just happens to work. Kind of like people turning off the Data not numeric - zero used errors.

Remember:

Attribute 8 produces the data that you select things on - correlative
Attribute 7 tells it how to format the output and how to convert a command line value to the value to look for  - conversion



Sorry for the brain fart but since we support so many MV
implementations, its hard to keep them all straight.

Yeah - this problem is propagated from very far back in the Pick code base, but because so many people refused to fix their dictionaries, we even had to emulate this at jBASE. It may be that Cache' has to do the same, but it is MUCH MUCH better to fix the dictionaries as the side effects are not always harmless - I could quite some choice ones form jBASE days, but I better protect the innocent. ;-) I suppose the worst examples was showing a company that their billing report had the wrong answers, but rather than fix this, they chose to go with a platform that gave the same wrong answers - they were too scared to tell their management that they woudl have to restate their accounts for the previous 8 years I think :-)

Jim

Reply all
Reply to author
Forward
0 new messages