×
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.
We have many files that are recreated each fiscal and calendar year end.
They are mainly detail files for A/R, O/E, and so on. The format of the
files is XXXYYN where XXX is related to the system, YY is the current year,
and N is any logical files. All of the files for the new year are created
automatically whenever a program that needs to update the detail files runs
in the new year. They are all built off of a dummy file.
As an example, our detail order entry file for 2007 would be OET07. The
first program that tried to add detail in 2008 created OET08. All of these
files have been built using a dummy file, OETXX. This file hasn't changed in
years. The problem started showing up as we convert all the legacy code to
external files.
Almost all of the programs that use the detail files have the XX version in
the file spec (OETXX if we follow the above example). It seems that
everytime a file gets created for the new year, nothing but level checks.
The program is compiled with OETXX and the new file is created using OETXX.
The only way to get around it is to compile with level check no, which I
don't want to do.
Any thoughts?
Kelley
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
