Re: A Difference between iACS and RUNSQLSTM on INSERT statement

Fails with what error?

Possibly something to do with localization... do a DSPJOB and check
Decimal format . . . . . . . . . . . . . . . . . : *BLANK
Language identifier . . . . . . . . . . . . . . . : ENU
Country or region identifier . . . . . . . . . . : US
Coded character set identifier . . . . . . . . . : 37
Default coded character set identifier . . . . . : 37

1, could be seen as the start of a decimal value if your job is configured
to use commas as a decimal separator.

In which case I'd expect the error to be something about an invalid number
or couldn't cast(convert) to a number.

You could also confirm via
INSERT INTO custmast (Name, CustID) VALUES ('John Smith',1);

The reason it works on ACS is that ACS is using the locality of your PC.

Charles

On Wed, Sep 6, 2023 at 3:05 PM Sam_L <lennon_s_j@xxxxxxxxxxx> wrote:

I have a table like this:
CREATE TABLE custmast (
CustID NUMERIC(4, 0) NOT NULL
,Name CHAR(40) NOT NULL
,PRIMARY KEY (Custid)
)
This insert statement works in iACS but fails in RUNSQLSTM:
INSERT INTO custmast (CustID,Name) VALUES (1,'John Smith');

However, this one works in RUNSQLSTM and iACS:
INSERT INTO custmast (CustID,Name) VALUES (1, 'John Smith');

The difference is the extra space after the ",". I had some more
extensive code that I ran with RUNSQLSTM back in 2022 (I think) on
PUB400 but it broke today.

Is this a known bug or feature?

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.