RE: Trigger pgm - SQL errors

Pete,

I would still rule out an OS/400 bug until you have done a bit more
tracing. AM+ could be doing something strange in ODBC that is normally
not seen because of the speed of the 400.

You may want to look at the stack on the job that is making the repeated
call to see exactly which program / line is creating the issue. A
further step would be to do a normal odbc read of GELMAS and see if the
same issue arises. If it does not, check the ODBC connection parameters
for the AM+ vs your odbc connection to see if there are differences.
Finally, if that fails turn on ODBC tracing for the AM+ connection to
see exactly what the application is doing. In that you should see the
connection SQL strings as they get executed.

HTH

Konrad



-----Original Message-----
From: Pete Olshavsky [mailto:polshavsky@xxxxxxxxx] 
Sent: Thursday, June 19, 2003 7:17 AM
To: MAPICS ERP System Discussion
Subject: RE: Trigger pgm - SQL errors


Malcolm, I tend to agree with you. I have never done this. Can you
explain how? Also I am an independant programmer. Will I need an IBM
customer no? Thanks Pete

Malcolm Westley <mwestley@xxxxxxxxxxx> wrote:
Pete,

Looks like you found an os400 bug. You should submit an APAR to ibm.

Malcolm

> From: Pete Olshavsky [mailto:polshavsky@xxxxxxxxx]
> Sent: Wednesday, June 18, 2003 9:12 AM
> To: MAPICS ERP System Discussion
> Subject: RE: Trigger pgm - SQL errors
>
>
> Basically the joblog pointed to error message CPF523D Too many 
> triggers called. Max 200.
>
>
> Dave Lauderdale wrote:
> Pete,
>
> What did the joblog tell you? I checked the message and it says to 
> refer to the joblog for additional information.
>
> David
>
> -----Original Message-----
> From: Pete Olshavsky [mailto:polshavsky@xxxxxxxxx]
> Sent: Wednesday, June 18, 2003 6:43 AM
> To: mapics-l@xxxxxxxxxxxx
> Subject: Trigger pgm - SQL errors [bcc][faked-from][mx]
>
>
> Morning list,
> I have a customer that wanted to put some kind of security over the 
> GELMAS file. We discussed on this thread about using AS400 security. 
> But the feeling I came away with was... Be careful be very very 
> careful. And be afraid. So the route we decided was to put a *read 
> trigger on the gelmas file. Which seems to be working perfectly. 
> Whenever anyone reads the file. Like a G/L audit. INquiry into an 
> acct, Query the file, Dfu the file. Program works like I want it to. 
> Now the Problem. If I go to AM+ in the browser and click the icon for 
> General ledger I get SQL trigger in failed SQLCODE SQLSTATE.
> I can barely spell SQL. So I really don't understand the error
message..
> But the best that I can tell and that Mapics support can tell is that
> SQL is reading records faster than the AS400 trigger pgm can process,
> and end. I have even tried to setup my CL to really do nothing more
than
> cancel if the user is QUSER. Is there a way to tailor SQL to slow down
> without affecting the other browser apps' or any other tricks not to
get
> the trigger pgm to fire?????
>
> I am not at that account today so I don't have the ability to test 
> anything. TIA
> Pete Olshavsky
> Ind Mapics Programmer/Systems Analyst
_______________________________________________
This is the MAPICS ERP System Discussion (MAPICS-L) mailing list To post
a message email: MAPICS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/mapics-l
or email: MAPICS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mapics-l.


---------------------------------
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
_______________________________________________
This is the MAPICS ERP System Discussion (MAPICS-L) mailing list To post
a message email: MAPICS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/mapics-l
or email: MAPICS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/mapics-l.