Re: SQL Update different on v7r3?

[Thomas Garvey <tgarvey@xxxxxxxxxx>]

No, it doesn't fail, but it does not do the replace in the same way.
That is, it does not disregard the lengths of the old and new values 
when doing the replace.

So, for example, if I have
/Drop Procedure Library/ProcedureName;//
/in the source member.
Executing the update with replace so that /Library/ might be replaced 
with Tom will result in...
/Drop Procedure Tom    /ProcedureName;/

While on v5r4 the same SQL execution results in...
/Drop Procedure Tom/ProcedureName;/

When a RUNSQLSTM is executed against the one with the embedded blanks 
will fail.

I'm open to suggestions.

Best Regards,

Thomas Garvey

On 1/8/2019 4:43 PM, Vernon Hamberg wrote:

> Hi Thomas
>
> It's not a 7.3 change - it was done sometime after v5r4 - the thing 
> now is, SQL assumes that literal values are VARCHAR, hence the 
> mismatch message.
>
> Does it cause the UPDATE to fail? I would not think so, it's just a 
> nuisance, I hope.
>
> HTH
> Vern
>
> On 1/8/2019 3:56 PM, Thomas Garvey wrote:
> > Hi,
> >
> > I've got a program that is used to replace a particular value found 
> > in source members with another value.
> > It uses the SQL update command, as follows...
> > update QSQLSRC set srcdta=replace(srcdta,'oldvalue','newvalue')
> >
> > This works fine on an old v5r4 box and the oldvalue and newvalue can 
> > have different lengths with no complaints
> > from SQL.
> > On a v7r3 box I get an SQL7939 message, saying 'Data conversion 
> > required on INSERT or UPDATE'.
> > The reason code is 3 (Reason 3 is that 'the INSERT or UPDATE value is 
> > a variable length string and column SRCDTA is not').
> >
> > I can't see any difference in the files between the systems.  In fact,
> > the file on v7r3 is just a transferred copy of the file from v5r4.
> >
> > What am I doing wrong, or what am I ignorant of here?
> >
> > Best Regards,
> >
> >
> > Thomas Garvey