Re: Ignoring messages in SQL scripts

If you are running these through Navigator, I am not aware of anything other
than the change to the reply list or, change the default answer to the
message that you receive in the joblog.

If you run them from the RUNSQLSTM, you might be able to specify the
severity level of (say) 99 and let everything run....

Of course, as you are probably aware, this is a data loss situation. ANY
records that have nulls will be tossed by the operation. The change from
allowing nulls to not null is one that should NOT be done without first
analysing the data in the file and resolving issues first.

The default for OS/400 fields is not null, and for SQL fields is to allow
nulls. This is unfortunate, as the field should only be allowed a null by an
overt act on the part of the designer. Again, this is where tools help a
great deal in the building and maintenance of databases. You can specify
that the default is not null on the tools and therefore reduce the
possibility of having to do something exactly like what you are trying to
accomplish.

===========================================================
R. Bruce Hoffman, Jr.
 -- IBM Certified Specialist - iSeries Administrator
 -- IBM Certified Specialist - RPG IV Developer

"If you pick up a starving dog and make him prosperous,
  he will not bite you. This is the principal difference
  between a dog and a man."

    - Mark Twain

----- Original Message -----
From: "McCallion, Martin" <martin.mccallion@misys.com>
To: <midrange-l@midrange.com>
Sent: Tuesday, November 05, 2002 7:05 AM
Subject: Ignoring messages in SQL scripts


> Hi all.
>
> I have written an SQL script which simply removes the null-capability
> from a column.  The entirety of the code is this:
>
> ALTER TABLE DVMLINK.INCOMINGMESSAGES ALTER COLUMN MOR SET DATA
> TYPE
> VARCHAR ( 28) NOT NULL;
>
> If I run this interactively in STRSQL, I get a program message which I
> can respond to with an 'I' to ignore.  When I run it from OpsNav, it is
> automatically answered with the cancel message.
>
> I know I could change the system reply list to force the 'I' answer, but
> we will be giving this to clients, and I'd like them just to be able to
> run the script, without having to change the reply list first and then
> remember to change it back afterwards.  Is there a way to tell the
> script to ignore the message?
>
> I can't find anything in the manuals, or on the web, except one exchange
> in the archives, where David Gibbs asked how to do the same thing in RPG
> with embedded SQL.  R. Bruce Hoffman, Jr. answered that he always did
> this in scripts (see
> http://archive.midrange.com/rpg400-l/200109/msg00327.html).
>
> So, David?  Bruce?  Anyone?
>
> TIA.
>
> Cheers,
>
> Martin.
>
> --
> Martin McCallion
> Senior Technical Consultant
> Work:  martin.mccallion@misys.com
> Home: martin.mccallion@ukonline.co.uk
> Misys International Banking Systems
> 1 St George's Road, London, SW19 4DR, UK
> T +44 (0)20 8486 1951
> F +44 (0) 20 8947 3373
> www.misys.com
> This email message is intended for the named recipient only. It may be
> privileged and/or confidential. If you are not the  intended named
> recipient of this email then you should not  copy it or use it for any
> purpose, nor disclose its contents to any other person. You should
> contact Misys International Banking Systems as shown below so that we
> can take appropriate action at no cost to yourself.
> Misys International Banking Systems Ltd,1 St
> George's Road, London, SW19 4DR, UK. Email: ibs.postmaster@misys.com.
> Tel: +44 (0) 20 8879 1188 Fax: +44 (0) 20 8947 3373
> Misys International Banking Systems Ltd is
> registered in England and Wales under company no. 971479
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>