13 replies to this topic

[jcjones]

I have a strange problem with an update function (one LU in particular).

Some background:
2 data files, 1 temporary file
This LU is to read data from data file 1, deletes the record from data file 1, then writes the data it read into the temporary file with small checks and modifications to the data. Then the following LU reads the data from the temporary file and writes it into data file 2.

Everything was working perfectly prior to adding a field to all 3 data files (both data files and the temporary file).

In the After Read No-ERR of the first data file (set to D mode), the new field that was added is not being read. The new field is fine in all other functions that access that particular field in the data file. I have used UMSG to trace the value of the field, no errors are encountered during the gen of this function, but when I display the value in the after read function, it's blank. I have verified that the field contains data in data file 1 prior to executing this function.

Other fields (that were present in the data file prior to adding this field) are read fine, and the data is transferred to the temporary file, but the new field is just ignored for some reason.

In this LU Data file 1 is mode D, the temporary file is mode A, After read no error is getting called from Data File 1, but the new field is empty always in that function, so it also has no value when the temporary file is written.

Any ideas?

Thanks,
JC

[Joseph Bove]

JC,

This is a bit of a long shot, but:

Are you checking the data in the file with functions built that read the same file definition or an overlay?

Several years ago, I'd see problems where a file definition and it's overlay had been coded inconsistently.

Example:

FILE1

K KeyField 3
A Alpha1 10
A Alpha2 15
A Alpha3 5

OVFILE1

K OVKeyField 3
A OVAlpha1 25
A OVAlpha2 15
A OVAlpha3 5

In a setup like this, if you wrote to OVAlpha2, you would actually be populating the first 5 characters of Alpha3 (as far as File1 is concerned).

...

One other idea:

Copy your update and set the file into Change and populate the field in question. Run the original and see if the field is still populated - or not.

hth,

Joseph

[Joseph Bove]

Guest,

If this were the case, would you ever be able to write to a file if the structure of the 2 files were not the same? Because, from what you stated you wouldn't be able to without some of the data being written to the wrong field, and possibly overwriting other data.

I'll give an extreme case.

The following two files (ProISAM) are identical

FILE1
ProISAM.pro

K KeyField 3
A AlphaField1 1
A AlphaField2 1
A AplhaField3 1
A AlphaField4 1

FILE2
ProISAM.pro

K KeyField 3
A AlphaField 4


As both reference the same physical file, they both have access to the same data. The parceling out of the data is based on each file's logical definition.

Let's say for argument sake the two logical definitions get out of synch. AlphaField5 is added to FILE1, but no similar change is made to FILE2. Now, if you read a record in Change mode from FILE2, it will blank out the value of AlphaField5.

I've also seen situations, with overlays where fields were just flat out missing. The results were very hard to understand until you could appreciate the differences in the file defs.

Regards,

Joseph

[Chris Pepper]

The following two files (ProISAM) are identical

FILE1
ProISAM.pro

K KeyField 3
A AlphaField1 1
A AlphaField2 1
A AplhaField3 1
A AlphaField4 1

FILE2
ProISAM.pro

K KeyField 3
A AlphaField 4

No this is just not true!

If we are talking about using the same ALTERNATE name to reference the same physical file from two FILE DEFINITIONS then it depends on the file type.

In a Pro-Isam indexed file the key is a fixed length string but the fields are separated by indicator bytes. This means each field is potentially a variable length. The system literally counts through the fields. So in the example above the second file will not over-write the field positions in the first file.

In this example if you write a record with FILE2 containing ABCD in AlphaField and subsequently read it back in FILE1 AlphaField1 will contain A and AlphaField2-4 will be blank. If the data is not written back by FILE1 then the original value will still be there if re-read via FILE2.

If you write a record using FILE1 and set the 4 fields to A, B, C and D and read it back using FILE2 then AlphaField will contain A. If the data is not written back via FILE2 then the original values will still be there when read via FILE1. If they ARE written back (e.g. using Change mode) then AlphaFields2-4 will disappear, because only fields known to the file definition are written back.

If the file type was fixed length SEQ, BIN, C-ISAM, External RMS then what Joseph says above IS TRUE. As these record types deal with strings of characters and not "fields".

Pro-Isam is more like SQL in the sense that it deals with separate elements, but note that ProIsam simply counts the fields - they are not related to the field name. So if you insert a field into a file definition you will get the data from whatever field was originally in that position. ProIsam indicates if a field is Alpha or Numeric, so if you insert a field of the wrong type into the file definition you will get a "DATA NOT ALPHA" message if any data is read from the file.

[Joseph Bove]

Chris,

Ok - I just tried this under 5.5 and stand corrected.

As I stated, it was several years, so I may be remembering something from as far back as 1.4 that no longer applies.

The one scenario that might be an issue for JC is if he's using an overlay and there are a different number of fields in the overlay. Then data could be "missing" from the last field when viewed from one file def but not from the other.

Regards,

Joseph

[jcjones]

Here's an update on the problem I was having, and another question (or two maybe.. ).

I let the original problem lay for a while since it wasn't critical, but I came across the problem again with a different file and a different set of functions. What I have found is that any update function that uses the modified file has to be re-genned or it will not read the new data fields.

Now for my question(s)

Is there a way to regen *all* of the functions so I don't have to research each function that uses a particular data file?

Are there any known problems with doing the above if it's possible to do that?

JC Jones

[Joseph Bove]

JC,

If you run @UM and choose option 18, and type P\

That should gen everything.

Regards,

Joseph

[jcjones]

Thanks Joseph,

When asked to press to start generation, I press return and immediately I get the ? prompt at the top of the screen and the following message at the bottom of the screen: "GENERATION IS BEING PERFORMED FOR SCREEN QUEUE#: 1"

At this point it does not appear to be doing anything, and at the ? prompt I have to enter the name of a function twice to leave that screen. Am I missing something?

JC Jones

[jcjones]

Ok, I think the problem with the regen was that there are more then 9999 functions in the gen list when using P\ with no other filters. After going one letter/character at a time (ie: P\A, P\B, .... P\%, P\@, etc.) I finally got through the entire list of functions.

There were around 50 functions and/or reports that would not gen - various errors, including some @ functions.

Do I need to worry about those functions that would not gen if they are not used, or is that an indication of corruption in the bootstraps somewhere?

JC Jones

[Anthony Downey]

JC,

You should not have to worry about the functions that did not gen PROVIDED they are not in use anymore. One method we use on old functions is to change their security category to one that the users do not have access to e.g. 'OBSOLETE'. Our menu selection ensures that only functions of specific categories can be accessed. This way if an 'OBSOLETE' function is selected the user will not be allowed access.

Regarding the bootstrap corruption, you can always do an ischk just to be sure.

Hope this helps,

Anthony

[George Macken]

Hi

Instead of Genning the complete system, On the @DM menu there is a File/Function x-ref option, identifies the functions that use a fiel and therefore those that you need to re-gen for a particular file. You should execute this for the changes File Definitions.

This function also has the ability to re-set function - this blanks the @FREV field on the functdef and this way the next time the function is executed it should re-gen before executing.

What you really need is a utility function that you can enter a file name and this automatically loads the Gen List and kicks off the batch gen

Are you developing in the Production Environment, if so be very careful ?

Rgds

George

[George Macken]

oops

"File/Function x-ref option
This function also has the ability to re-set function - this blanks the @FREV field on the functdef and this way the next time the function is executed it should re-gen before executing."

Dont use the re-set function option in the File Function X-ref as this rule only applies to functions BUT not the Global Functions. "663 - Cannot Auto-Reset Global Function"

hth

George