× 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.



Dennis

Are you sure of this? I think the FILE level ID is the timestamp of when the file is created. I just made a copy of the source for a PF and compiled the copy. The format level IDs were identical, since they are based on data types and other things, as described here in database fle management docs -

The server assigns a unique level identifier for each record format when it creates the associated file. The server uses the following information to determine the level identifier:

* Record format name
* Field name
* Total length of the record format
* Number of fields in the record format
* Field attributes (for example, length and decimal positions)
* Order of the field in the record format


Am I missing something? Ake's example has the same format level IDs and different file level IDs, which I'd expect. AFAIK, only format level IDs are looked at when using CPYF - I wonder what message he is really getting. I just tried a CPYF to the file I just created. I didn't use the CHGPF, as he did, over a duped file that was then made multi-member, so I may have a different test case.

Vern

On 8/17/2010 4:03 AM, Dennis Lovelady wrote:
Where you went wrong was in changing the two files independently. The
system uses timestamp to generate the format level ID, and the timestamps of
the two files cannot match. It doesn't matter that the format names, field
names etc. are the same since those don't generate the format level ID.

To correct this, create a new log file and repopulate it. Then eliminate
the old (save it first). Here's one way:

CPYF lib/DATAFILE lib/NEWLOG CRTFILE(*YES) TOMBR(some_unique_value)
CPYF lib/OLDLOG lib/NEWLOG FROMMBR(*ALL) TOMBR(*FROMMBR) FMTOPT(*MAP)
RNMOBJ lib/OLDLOG *FILE SAVEME
RNMOBJ lib/NEWLOG *FILE OLDLOG

Or thereabouts.

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"The direct use of force is such a poor solution to any problem, it is
generally employed only by small children and large nations."
-- David Friedman


I started out with one data file and a log-file that was created as a
copy of same file (CRTDUPOBJ). The log file has then been changed to
allow multiple members.



Now when new fields had to be added to the data file we also had a need
to keep the log file format in synch.



I did a CHGPF of the log file with the SRCFILE parameter and indicated
the source member that was used for the re-compile of the data file.



As far as I can see both files have the same record size, fields, field
types and field lengths.



Despite this I get a level check when using the CPYF to copy data from
one file to the other.



Where did I go wrong - OR is the only safe way to reformat files the
old trusted way of recompile and manual copying of the data?



File level id:s:

Data file 1100813084024

Log file 1100813084348



Format id:

Data file 42A0FD7F7A38F

Log file 42A0FD7F7A38F







Med vänlig hälsning / Best regards


Åke H Olsson



Box 433 SE 551 16 Jönköping Sweden visit: Brunnsgatan 11

phone: +46 (0)36 342976 mobile: +46 (0)705 482976 fax: +46 (0)36 34
29 29

ake.olsson@xxxxxx<mailto:ake.olsson@xxxxxx> www.pdb.se





This e-mail and any attachments may contain confidential and privileged
information. If you are not the intended recipient, please notify the
sender immediately by return e-mail, delete this e-mail and destroy any
copies. Any dissemination or use of this information by a person other
than the intended recipient is unauthorized and may be illegal.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.