Output table freezing

Richard Kreiss rkreiss at verizon.net
Fri Dec 22 10:38:48 PST 2017 

Top post,

Mark, I am not disagreeing with you, all am saying is that to know it is
record 43 then one has to have a way to see that it is record 43.  Once one
knows what the record is, it can be examined to see what the issue may be.
The programming can then be set to look for this issue and correct it if
possible.  

In a different file, this may not be the same record but may present the
same issue.

I had a problem with a -v select process because an incorrect date was
entered. The office manager was typing too fast and entered date(s) out of
range. She sometimes type 29NN instead of 20NN,  I ended up putting a check
in the what century was entered.  All of the dates had to be 20NN.  I did
but in a check for what century the current date was.  I just don't think I
or my client will be around in 80 plus years.  I'll let someone else worry
about this issue.  It would be nice if filePro is around then. 

Richard

> -----Original Message-----
> From: Filepro-list [mailto:filepro-list-
> bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of Fairlight
via
> Filepro-list
> Sent: Thursday, December 21, 2017 1:12 PM
> To: filepro-list at lists.celestial.com
> Subject: Re: Output table freezing
> 
> I disagree, depending on -when- it's random.  If it's random during the
reading of
> the file in sequential order, or defined by an unchanged index based on
the same
> data, I entirely disagree.  Then it should always bail out at the exact
same
> record, given the same sort/selection criterion.
> 
> If you have 100 records, and record 43 is bad, it should always bail at
record 43,
> unless a bad record is put into the mix at a place before record
> 43 would be gotten to.  If the file and indexes don't change, the results
should
> be consistent.  Hardwired algorithms don't change, so the data must be
> changing for it to be random.
> 
> m->
> 
> On Thu, Dec 21, 2017 at 01:05:08PM -0500, Richard Kreiss thus spoke:
> > Mark,
> >
> > Random only means that it is possible that the same issue occurs in
> > different places(records) within the file.  If he can find a record
> > that is causing the issue, ;he may be able to correct the problem.
> >
> > His other choice would be to post this data into a "real" filePro file
> > and check it for anomalies.  He may need to run a pre-process on this
> > file to clear-up an anomalies in the data before linking.
> >
> > Richard
> >
> >
> >
> > > -----Original Message-----
> > > From: Filepro-list [mailto:filepro-list-
> > > bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of
> > > bounces+Fairlight
> > via
> > > Filepro-list
> > > Sent: Thursday, December 21, 2017 12:35 PM
> > > To: filepro-list at lists.celestial.com
> > > Subject: Re: Output table freezing
> > >
> > > Yeah, but he said the freezes were random.  That doesn't point to
> > > one
> > specific
> > > record, in my book.  Not unless the random nature is triggered by a
> > rewrite of
> > > the alien file with different data, anyway.
> > >
> > > m->
> > >
> > > On Thu, Dec 21, 2017 at 05:27:20PM +0000, Richard Kreiss via
> > > Filepro-list
> > thus
> > > spoke:
> > > > Top Post:
> > > >
> > > > Had the same issue of program running with dclerk and not rclerk.
> > > >
> > > > Sometimes I could find the problem with the debugger other times
not.
> > What I
> > > usually do in this case is put up a show statement showing the
> > > record
> > number
> > > and a key value.  The issue is that most times the show statement is
> > > for
> > the
> > > record before the one causing the issue.  When you know the sort
> > > sequence, you can then find the next record and check it for bad
> > > data which can
> > cause the
> > > process to hang.
> > > >
> > > >
> > > > Richard Kreiss
> > > > GCC Consulting
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Filepro-list [mailto:filepro-list-
> > > > > bounces+rkreiss=verizon.net at lists.celestial.com] On Behalf Of
> > > > > bounces+Boaz
> > > > > Bezborodko via Filepro-list
> > > > > Sent: Wednesday, December 20, 2017 12:22 PM
> > > > > To: filepro-list at lists.celestial.com
> > > > > Subject: Re: Output table freezing
> > > > >
> > > > >
> > > > > Date: Tue, 19 Dec 2017 17:20:06 +0000 (UTC)
> > > > > > From: Richard Tartaglia <fp_rich at yahoo.com>
> > > > > > To: FP List <Filepro-list at lists.celestial.com>
> > > > > > Subject: Output table freezing
> > > > > > Message-ID: <837793377.1240627.1513704006974 at mail.yahoo.com>
> > > > > > Content-Type: text/plain; charset="utf-8"
> > > > > >
> > > > > > Hello to everyone. Happy Hanukkah Merry Christmas I am running
> > > > > > Fileprp
> > > > > > 5.0.14 on a Server running Windows 2013 operating system.
> > > > > > Filepro is on a mapped drive to my desktop running Windows 7.
> > > > > > I have a Filepro database that uses an alien file that is
> > > > > > deleted and downloaded
> > > > > for each run. All of my other tables in this file run fine.
> > > > > > The table that is stopping without an error, just stalls at
> > > > > > different points is 264
> > > > > lines long with 12500 records.
> > > > > > I thought it was looping somewhere and ran it in debug mode.?
> > > > > > It ran fine in
> > > > > debug mode. Problem is it will take 20 hours to run the table in
> > > > > debug
> > mode.
> > > > > > I am at a loss. Any thoughts would be greatly appreciated.
> > > > > > Tha
> > > > > >
> > > > > > Rich Tartaglia
> > > > > >
> > > > > > Go easy on me Mark. I am hoping I stated the problem okay.?
> > > > > >
> > > > > >
> > > > > > ?
> > > > > >
> > > > > >
> > > > > > |  | Virus-free. www.avg.com  |
> > > > > >
> > > > > > -------------- next part -------------- An HTML attachment was
> > > > > > scrubbed...
> > > > > > URL:
> > > > > > <http://mailman.celestial.com/pipermail/filepro-list/attachmen
> > > > > > ts/2
> > > > > > 0171
> > > > > > 219/1c99189f/attachment.html>
> > > > > >
> > > > > > ------------------------------
> > > > > >
> > > > > >
> > > > >
> > > > > Are you running the program with rclerk as opposed to dclerk?
> > > > > I've had a few rare occurrences where running a program with
> > > > > dclerk (what debug uses) instead of rclerk made the program run
> > > > > correctly as it would under debug.
> > > > >
> > > > > ---
> > > > > This email has been checked for viruses by Avast antivirus
software.
> > > > > https://www.avast.com/antivirus
> > > > >
> > > > > _______________________________________________
> > > > > Filepro-list mailing list
> > > > > Filepro-list at lists.celestial.com
> > > > > Subscribe/Unsubscribe/Subscription Changes
> > > > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > > > -------------- next part -------------- A non-text attachment was
> > > > scrubbed...
> > > > Name: winmail.dat
> > > > Type: application/ms-tnef
> > > > Size: 13878 bytes
> > > > Desc: not available
> > > > URL:
> > > > <http://mailman.celestial.com/pipermail/filepro-list/attachments/2
> > > > 0171
> > > > 221/91993dae/attachment.bin>
> > > > _______________________________________________
> > > > Filepro-list mailing list
> > > > Filepro-list at lists.celestial.com
> > > > Subscribe/Unsubscribe/Subscription Changes
> > > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> > > >
> > >
> > > --
> > > Audio panton, cogito singularis.
> > > _______________________________________________
> > > Filepro-list mailing list
> > > Filepro-list at lists.celestial.com
> > > Subscribe/Unsubscribe/Subscription Changes
> > > http://mailman.celestial.com/mailman/listinfo/filepro-list
> >
> >
> 
> --
> Audio panton, cogito singularis.
> _______________________________________________
> Filepro-list mailing list
> Filepro-list at lists.celestial.com
> Subscribe/Unsubscribe/Subscription Changes
> http://mailman.celestial.com/mailman/listinfo/filepro-list

More information about the Filepro-list mailing list