Re: Embedded SQL weirdness

[DAsmussen@xxxxxxx]

Mark,

In a message dated 1/17/99 2:03:06 AM Eastern Standard Time, mlazarus@ttec.com
writes:

> >Only if the transaction is rolled back instead of commited.  Best to
>  define in
>  >the program your intention with EXEC COMMIT WORK.If the file is not
>  journaled, it
>  >won't work anyway.  If it was created by CREATE TABLE in a *real*
>  collection, the
>  >journal will be there.
>  
>   Again, this is not the behavior I experienced.  When the program was
>  compiled w/ CRTSQLRPG COMMIT( *CHANGE ), the updates did not occur.  After
>  compiling w/ COMMIT( *NONE ) it worked.

Ahh, the pattern emerges!  The files must be journaled on your system.  I ran
into this a few weeks ago, and about drove myself crazy trying to figure out
what happened because the environment in which I was testing was not
_supposed_ to be journaled.  I forgot to change the compile defaults on an SQL
program, which is normally not a problem because the job will tank when run
against unjournaled data and remind me to recompile correctly.  Unfortunately,
my test environment had recently been refreshed from production and the
journals were not removed, as is the usual procedure.  My program threw all
the records into the commitment buffer, and I lost half a day trying to debug
why it wasn't working.  Compiling with COMMIT(*NONE) corrected the problem,
after I issued a COMMIT from the command line on a lark and my data
"magically" appeared.  Apparently, issuing the STRCMTCTL command prior to
using commitment control is no longer a prerequisite.

HTH,

Dean Asmussen
Enterprise Systems Consulting, Inc.
Fuquay-Varina, NC  USA
E-Mail:  DAsmussen@aol.com

"If you haven't got anything nice to say about anybody, come sit next to me."
-- Alice Roosevelt Longworth
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---