Re: SQL Acting Strangely

[CRPence <CRPbottle@xxxxxxxxx>]

  To be clear, it was not that the "job" had the decimal separator 
set to a comma, it was that the "interactive SQL session" had the 
decimal separator set to a comma.  And... Once the session has its 
attributes established, changing the specification via the command 
parameter does not change the session attribute that is already set. 
 Instead the F13=Services must be used to modify the settings on an 
existing session.  Note that when the STRSQL DECPNT(somevalue) is 
issued, if an existing session is opened instead of a new session 
being started, then a msgSQL6335 is logged in the session to notify 
that the parameter was ignored.  Admittedly, when the session was 
initially created, the DECPNT(*JOB) had likely established the comma 
as decimal separator for that SQL session [object].

  The blank after a comma is good practice to ensure that a 
statement formed when using a session having the period as the 
decimal point, will still be valid when pasted into a session using 
the comma as decimal point\separator.  FWiW it is courteous to add 
the blank when publishing statements [e.g. to a newsgroup] so that 
when someone in another language environment might want to perform 
the same SQL, they will not have to /correct/ the statement to make 
it function without the syntax error.

Regards, Chuck

Jonathan Mason wrote:
> Thanks Birgitta
>
> I'll make sure of that in the future. Sean had already put that 
> forward as the solution, but when I specify *PERIOD as the
> decimal point in STRSQL it still gives the same error.
>
> Not to worry, I'll make sure the blanks are included in future.
>
> Birgitta Hauser wrote:
> > Your job is using a comma as decimal point.
> > To avoid those problems always enter a blank after a comma:
> >
> > Substr(BJOAT2, 8, 8)