MS error

John Esak john at valar.com
Mon Jan 25 12:59:41 PST 2010


Yes, I tried to write that near the end of the note... Must have expressed
it badly. I think in my early testing I was getting a true for SysStat eq
"0" and it wasn't... So I'm wondering if maybe it'b being declared and
immediately used... It is already "", so if the system call doesn't change
the return value, the "" is there ready to be evaluated as "0"  since I have
the edit type set to .0.   I wouldn't think this step is really necessary,
but I do it just for grins.  I also sometimes CLEAR arrays after they have
been DIM'd also... And this isn't necessary either.  Just that, as you know,
from really, really long ago and far away, sometimes variables in BASIC
would come up already having a value!  I rmember Bob Snapp building a
program called Garhage Collector to clean up such strangeness.  Anyway, some
of my old habits hung on.

J

> -----Original Message-----
> From: Richard Kreiss [mailto:rkreiss at verizon.net] 
> Sent: Monday, January 25, 2010 2:41 PM
> To: john at valar.com
> Subject: RE: MS error
> 
> John,
> 
> Thanks for the suggestion.
> 
> One quick question, I am assuming that when you set 
> sysstat="999" you are insuring that it is not blank or "0" to 
> start with.  Am I correct?
> 
> Richard
> 
> PS - this should have been documented as this is like EXIT()
> 
> 
> 
> > -----Original Message-----
> > From: 
> filepro-list-bounces+rkreiss=verizon.net at lists.celestial.com 
> [mailto:filepro-
> > list-bounces+rkreiss=verizon.net at lists.celestial.com] On 
> Behalf Of John Esak
> > Sent: Monday, January 25, 2010 11:08 AM
> > To: rkreiss at gccconsulting.net; 'Kenneth Brody'
> > Cc: filepro-list at lists.celestial.com
> > Subject: RE: MS error
> > 
> > Richard, Nancy,
> > 
> > I've got an idea for your crashing thing... And maybe 
> Nancy's or other's.
> > 
> > It's a little hard to go from your description rather than 
> the actual code... But
> > check whether the file you are opening to post the cc data 
> and read later gets
> > closed correctly between transactions. I'd check to be sure 
> the detail record is
> > written each time, even though it is probably a free record 
> lookup each time...
> > Still do a write to finish off that lookup/post. Of course, 
> this is a situation where
> > you do NOT want to do CLOSE's... If you are doing 100 to 
> 500 transactions in a
> > shot that will slow you down too much.
> > 
> > Now, also, in some cases, it could be a timing issue when 
> opening and closing
> > the files which the other outside program accesses when it 
> sends and retrieves
> > the data.
> > 
> > It sounds as if the process which is CALL'd or run with a 
> SYSTEM command
> > must be the one that is dying... Not the main *report. I 
> can easily see how things
> > would keep going in this scenario. A crash for the CALL'd program or
> > SYSTEM'd program would probably not cause the main *report 
> to crash. It will
> > return a bad "success code though which you can intercept 
> with the SYSTEM
> > command.... Just treat the SYSTEM command as a function.  
> This is a VERY
> > neat trick Ken showed me a while back that allows you to 
> test the return value of
> > your SYSTEM commands.  Just put it in as the argument of 
> the SYSTEM()
> > function... Like this:
> > 
> >    then: xx=system("command")
> > 
> > Now you can test the variable XX for the return value as to 
> whether the
> > SYSTEM command failed or not.  Perhaps, as long as the 
> command "passes",
> > you keep a counter.  When it "fails", you will at least no 
> how many iterations of
> > the command caused the problem. This, of course, may be 
> very random and/or
> > not significant for a variety of reasons, but then again it 
> may help you diagnose
> > the real problem.
> > 
> > Here is a snip of a subroutine that will show exactly how 
> to check something like
> > this... Maybe you or Nancy could employ this type of code 
> to get to the bottom of
> > what is causing your issues.  I will tell you that in this 
> case, I was having a timing
> > issue.... Very, very frustrating because it did what was 
> happening to you guys
> > and apparently with no rhyme or reason.  So, I put the 
> SLEEP "xxx" command in
> > to try and fix it... Would you believe that in this 
> particular case the "7000" works
> > perfectly every time over and over... But if I use "6000" 
> it doesn't! and above
> > "7000" causes *other* even worse problems.  So, believe me 
> I don't pooh-pooh
> > timing issues on Windows anymore. By the way I force a 
> non-zero value into the
> > return value of the SYSTEM command (SYSSTAT) just to be 
> sure I know the
> > value "0" if I get one is actually put into that var from 
> executing the command,
> > not because of some other errant clearing of it.
> > 
> > 
> > 433  -------   -   -   -   -   -   -   -   -   -   -   -   
> -   -   -   -   -
> >        ? If:
> >        Then: declare sysStat(8,.0);  sysstat="999"
> > 434  -------   -   -   -   -   -   -   -   -   -   -   -   
> -   -   -   -   -
> >        ? If:
> >        Then: SysCmd="net use" < map_to_this_drive < 
> "/delete >nul" { ""
> > 435  -------   -   -   -   -   -   -   -   -   -   -   -   
> -   -   -   -   -
> >        ? If:
> >        Then: SysStat=system(SysCmd)
> > 436  -------   -   -   -   -   -   -   -   -   -   -   -   
> -   -   -   -   -
> >        ? If:
> >        Then: sleep "7000"
> > 437  -------   -   -   -   -   -   -   -   -   -   -   -   
> -   -   -   -   -
> >        ? If: SysStat ne "0"
> >        Then: errorbox "Failed disconnect from other 
> system.\nDO IT MANUALLY"
> > 438  -------   -   -   -   -   -   -   -   -   -   -   -   
> -   -   -   -   -
> >        ? If:
> >        Then: return
> > 
> > 
> > I really hope this helps to get rid of some of these long 
> standing, nagging
> > problems.
> > 
> > Good luck,
> > 
> > John Esak
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: filepro-list-bounces+john=valar.com at lists.celestial.com
> > > [mailto:filepro-list-bounces+john=valar.com at lists.celestial.co
> > m] On Behalf Of Richard Kreiss
> > > Sent: Monday, January 25, 2010 10:03 AM
> > > To: 'Kenneth Brody'
> > > Cc: filepro-list at lists.celestial.com
> > > Subject: RE: MS error
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Kenneth Brody [mailto:kenbrody at spamcop.net]
> > > > Sent: Thursday, January 21, 2010 10:33 PM
> > > > To: rkreiss at gccconsulting.net
> > > > Cc: filepro-list at lists.celestial.com
> > > > Subject: Re: MS error
> > > >
> > > > On 1/21/2010 4:56 PM, Richard Kreiss wrote:
> > > > > One of my clients is getting the following error message
> > > > >
> > > > > Exception error -1073741819 in process failed 0(0x00000000)
> > > > > comspec="(null)"
> > > > > command="F:\fp56\fp\rreport transaction -f approvals -v
> > > sel_process -a
> > > -iK
> > > > > -u
> > > > [...]
> > > > > Question; does anyone know what this exception refers to?
> > > >
> > > > It's 0xc0000005 (STATUS_ACCESS_VIOLATION), which Microsoft
> > describes
> > > > as
> > > > "Reading or writing to an inaccessible memory location".  I
> > > believe it's
> > > > similar to a Unix "segmentation violation".
> > > >
> > > > Note that rreport did _not_ continue running after you
> > > pressed Enter, as
> > > > rreport had already exited when the error was displayed.
> > >
> > > Ken,
> > >
> > > My client has told me that the process continues after this
> > > error appears
> > > and is not at the end.
> > >
> > > This is a process which is processing credit card charges.
> > > Anywhere from 100
> > > to 500 charges at a time.  The program is writing out an html
> > > file, calling
> > > an outside program to transmit the file, and then reading 
> back in the
> > > result.  The resulting information is then is hashed and
> > > applied to the
> > > current record, a detailed payment record is created, if the
> > > transaction has
> > > been approved, and the sales journal is updated.
> > >
> > > I have to believe my client when they tell me the approval process
> > > continues.  The only thing that has not happened is the
> > > updates for the
> > > current transaction.  I think that the error may have
> > > occurred when posting
> > > to the sales journal as this was the only lookup I failed to
> > > protect.  I
> > > have since changed the code and will have to wait to see 
> if this error
> > > occurs again.
> > >
> > > Richard
> > >
> > > _______________________________________________
> > > Filepro-list mailing list
> > > Filepro-list at lists.celestial.com
> > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > >
> > 
> > _______________________________________________
> > Filepro-list mailing list
> > Filepro-list at lists.celestial.com
> > http://mailman.celestial.com/mailman/listinfo/filepro-list
> 
> 



More information about the Filepro-list mailing list