Escaping the & (ampersand) character

[GregW]

I have an xml select query like this:

                  select unique office
                  from organizations
                  where organization = #{org} and department = #{dept}

In my case, some of the department values may contain the character
'&' in them.  Examining the logs, the org and dept get filled in with
the correct values, however the dept which contains a '&' I guess is
not being escaped and therefore is not a legal SQL query.  Is there a
way around this?  Am I missing something?

-Greg

[Eduardo Macarron]

Hi Greg, I am not sure I understood the problem. Could you post the log?

El día 19 de abril de 2012 17:32, GregW <[hidden email]> escribió:

> I have an xml select query like this:
>
>                  select unique office
>                  from organizations
>                  where organization = #{org} and department = #{dept}
>
> In my case, some of the department values may contain the character
> '&' in them.  Examining the logs, the org and dept get filled in with
> the correct values, however the dept which contains a '&' I guess is
> not being escaped and therefore is not a legal SQL query.  Is there a
> way around this?  Am I missing something?
>
> -Greg

[GregW]

Sorry, apparently it does work.  My colleague was experiencing some
difficulties but I see that myBatis is doing the correct thing.

-Greg

On Apr 19, 11:38 am, Eduardo Macarron <[hidden email]>
wrote:

> Hi Greg, I am not sure I understood the problem. Could you post the log?
>
> El día 19 de abril de 2012 17:32, GregW <[hidden email]> escribió:
>
>
>
>
>
>
>
> > I have an xml select query like this:
>
> >                  select unique office
> >                  from organizations
> >                  where organization = #{org} and department = #{dept}
>
> > In my case, some of the department values may contain the character
> > '&' in them.  Examining the logs, the org and dept get filled in with
> > the correct values, however the dept which contains a '&' I guess is
> > not being escaped and therefore is not a legal SQL query.  Is there a
> > way around this?  Am I missing something?
>
> > -Greg