Carey,
What do you think is the functional difference between the following:
(They look like they would produce the same thing to me.)
> So in theory this would expand to:
>
> ('Account Name' LIKE "ACCOUNT NAME"+"%")
>
> Whch isn't really what I want, what I really want is:
>
> ('Account Name' LIKE "ACCOUNT NAME%")
To me also there appears to be no difference, however when the
webservice expands the query I get no entries in the database using
option1 and 7 if I use option 2... made no sense..
I have more testing to do tomorrow, in that I'm going to test inside
the user tool and not the webservice just to be sure I'm not going
bonkers ;-)
However, one option would be to set up the Web Service as this...
('Account Name' LIKE XPATH(/ROOT/Account_name))
Then tell the Web Service client to pass in a value for Account_name
that ends in a "%".
Also keep in mind that they could just as easily pass in this value
too "%ACCOUNT NAME" and not have the trailing "%" in that case.
Yes that's what I told them they should do and I just get back "oh
that's too much effort your webservice should hanndle this for us"
You might even opt for several operations that would allow the
WebServices client to choose if they want a LIKE with a forced
trailing "%", just a straight LIKE qualification, or maybe even the
old equals search as a third option.
Yup thought about this too, but until I can do the forced '%' in the
webservice definition these are not an option, I'm trying to be as
flexible as possible but it doesn't help when your 'customers' are
also being flexible...
Thanks for the suggestions so far though....
Stephen
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org ARSlist:"Where the Answers
Are"
