× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Dear Al ....

Yes, amen! This line from your post is 100% on the mark:

"I believe one also needs to go to each of the dependency files
to locate any records which lack their relevant parent match."

That is exactly what Locksmith does to repair prior purge efforts that left
behind data
orphans. If you run Locksmith and point it at the purchasing area, then when
Locksmith is done, you will have no more orphan records. They'll all be
archived
for you in a different library using the same file structure as vanilla
BPCS/ERP LX.

Peace,
Milt
mhabeck@xxxxxxxxxx




From: Al [mailto:macwheel99@xxxxxxxxxx]
Sent: Tuesday, September 06, 2011 12:14 PM
To: 'Milt'
Subject: RE: [BPCS-L] cleaning up data orphans in purchasing and elsewhere
---BPCS + ERP LX

Thanks for your post to BPCS-L regarding the latest glitch I was asking for
info.
I found out about this glitch end last week, spent some time exploring it
over the weekend, decided to ask BPCS-L in case I overlooked anything
critical, since BPCS documentation is incomplete, not in any one consistent
location, and often as clear as mud.

I had been using UPI Locksmith on a variety of files, but not keeping good
records or memory on which ones when.
I was pretty sure I had used UPI on Pos, but now plan to do so during a soon
weekend, before writing program I think is needed to deal with this.

Before we got UPI archiving, I had been struggling with writing programs to
deal with this piecemeal, attacking 2 kinds of files:
. BPCS files eating humongous disk space, with no apparent built in
software to organize purges of no longer wanted records.
. BPCS files running out of numbers, like order #s, invoice #s.
Over the weekend I determined that the Pos had not been included in that
effort.

Minor nit pick ... your statement about using HPH as starting point ...
there is a potential hole in that logic, common to BPCS overall. When header
record is used as master, the logic search often fails to find related
records which are orphans without header record. I believe one also needs to
go to each of the dependency files to locate any records which lack their
relevant parent match.

Al Mac





From: bpcs-l-bounces@xxxxxxxxxxxx [mailto:bpcs-l-bounces@xxxxxxxxxxxx] On
Behalf Of Milt
Sent: Tuesday, September 06, 2011 9:59 AM
To: BPCS user group
Subject: [BPCS-L] cleaning up data orphans in purchasing and elsewhere
---BPCS + ERP LX

<vendor>



Good morning ...

The way to fix that is to use the HPH file as a starting point and then
compare data in all the dependent files to HPH. If there is no match, then
archive the dependent file record(s). Locksmith software does that. It works
equally well in the other principle business processes.
(www.unbeatenpath.com/software/locksmith/archiving.pdf )

It's conceivable that the problems that Al and Dick cite were caused because
at some prior time, an analyst decided to purge HPH records without knowing
all the places to look for dependent data. Locksmith archiving software
arrives with all of those data dependencies pre-configured. In the case of
customer orders, I believe at least 13 dependent files are involved. So, it's
no small trick to avoid a case of BPCS/ERP LX data orphans when you purge.

Warm regards,
Milt Habeck
Unbeaten Path
(888) 874-8008
+262-681-3151


</vendor>



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.