APPX is the Premier Development and Runtime Environment for Business Application Software
(Category) (Category) FAQ's - APPX Software, Inc. : (Category) APPX Utility : (Category) APPX Development Environment :
Data Dictionary
FAQ's relating to the use of the APPX Data Dictionary.
Subcategories:

Answers in this category:
(Answer) How many fields can be defined for a file in the Data Dictionary?
(Answer) I changed the alignment of the field from left to right but the sorting remains the same, why?
(Answer) Can I invoke another process in a FLEP?
(Answer) FLEP’s may not execute when the cache priority it set to 1.
(Answer) What is the scope of a FLEP?
(Answer) Can I pass information into a FLEP?
(Answer) How many times does Post-PCF Read FLEP fire?
(Answer) Do many duplicate keys decrease the performance?
(Answer) Can ERROR statement be used in FLEP's?
(Answer) FLEP questions
(Answer) I want to delete fields from a file in my DD, but those fields contain data, should i delete the data first?
(Answer) I added a new value to a validation table and it’s not listed at run-time, why?

[New Answer in "Data Dictionary"]
2007-Jul-13 3:57pm
(Answer) (Category) FAQ's - APPX Software, Inc. : (Category) APPX Utility : (Category) APPX Development Environment : (Category) Data Dictionary :
How many fields can be defined for a file in the Data Dictionary?
The maximum size of a record in APPX is 32767 bytes. There is no limit on the number of fields as long as the cumulative length doesn't exceed this 32K maximum APPX record length.

Maximum record length is regardless of file type (AppxIO, Oracle, Sybase, SQL Server, PostgreSQL, etc.).

[Append to This Answer]
2003-Nov-26 12:19pm
(Answer) (Category) FAQ's - APPX Software, Inc. : (Category) APPX Utility : (Category) APPX Development Environment : (Category) Data Dictionary :
I changed the alignment of the field from left to right but the sorting remains the same, why?
When you change the justification in the data dictionary the structure file is rebuild but not the data file. The result of this is the sequencing of the data is unaffected by the change of the justification. This is a documented bug and will be corrected in a future release of APPX (Bug #768). In order to get the change in justification to effect the file (data), you have to force it to restructure the entire file (add a field or change the length of a field) or write an update to read each record and simply set the field into itself and rewrite the record. This will put the data in the correct order.
[Append to This Answer]
2003-Dec-26 1:35pm
(Answer) (Category) FAQ's - APPX Software, Inc. : (Category) APPX Utility : (Category) APPX Development Environment : (Category) Data Dictionary :
Can I invoke another process in a FLEP?
No, although you can have a COPY or a GOSUB. Furthermore, only the record buffer is shared between FLEP's and the controlling process. This is by design. When ASI designed this feature, we felt that the FLEP's should only be used for "generic" ILF code. That is, ILF code that should always be run unconditionally in conjunction with file I/O. For example, we felt like it would be inappropriate for a FLEP to execute ILF code conditionally depending on the name of the controlling process. Code that is specific to a particular process should be in an event point of the actual process, not in a FLEP.

However, with experience comes wisdom. We now agree that there are situations where it is desirable and even necessary to share some additional information between the controlling process and the FLEP's. We will be reviewing the functionality of this feature in the near future.

[Append to This Answer]
2004-Feb-13 8:38am
(Answer) (Category) FAQ's - APPX Software, Inc. : (Category) APPX Utility : (Category) APPX Development Environment : (Category) Data Dictionary :
FLEP’s may not execute when the cache priority it set to 1.
This is a documented bug in APPX 4.2.2 and below. If the initial cache priority is 1, FLEP’s may not execute as they should. Try setting the cache priority to 2 instead (for now).
[Append to This Answer]
2004-Feb-13 8:39am
(Answer) (Category) FAQ's - APPX Software, Inc. : (Category) APPX Utility : (Category) APPX Development Environment : (Category) Data Dictionary :
What is the scope of a FLEP?
Currently, only the record buffer is shared between the FLEP and the controlling process (work fields are not shared either). This is by design. When ASI designed this feature, we felt that the FLEP's should only be used for "generic" ILF code. That is, ILF code that should always be run unconditionally in conjunction with file I/O. For example, we felt like it would be inappropriate for a FLEP to execute ILF code conditionally depending on the name of the controlling process. Code that is specific to a particular process should be in an event point of the actual process, not in a FLEP.

However, with experience comes wisdom. We now agree that there are situations where it is desirable and even necessary to share some additional information between the controlling process and the FLEP's. We will be reviewing the functionality of this feature in the near future.

[Append to This Answer]
2004-Feb-13 8:40am
(Answer) (Category) FAQ's - APPX Software, Inc. : (Category) APPX Utility : (Category) APPX Development Environment : (Category) Data Dictionary :
Can I pass information into a FLEP?
Yes and No. The way you pass more information into a File Level Event Point (FLEP) is by adding more fields to the record buffer for that file.

For instance, if you need to pass in a POST TO HISTORY flag so that the FLEP knows if it should update the HISTORY file from this record. You would add this flag to the data dictionary for the file. It doesn't hurt to have it there and stored with the record. Doing so lets you know at a later date which records have been posted to history. Being part of the record makes it visible and obvious that the data element is there and needs to have a value for the FLEP code to execute properly. This is visible and passed regardless of when, how, and why the FLEP fires. By an APPX Process, an ILF Write, an AppxODBC Rewrite, etc. it doesn't matter.

The FLEPs that are associated with a file only share the file record buffer with the processes that trigger them. Additionally, the standard PASS and RECEIVE statements will not work to pass data in and out of FLEPs.

This is by design. There are a number of reason for this restriction.

1)Work field and file fields other than those in the FLEP record buffer used in a process are protected from being stepped on by any FLEP code that might fire during the running of that process.

2) FLEPs run as a separate process and don't always fire in a procedural fashion as a design might expect. They are event driven and fire anytime Appx reads, writes, rewrites, or deletes a record. There are times when Appx does this automatically for the designer. And also times when FLEPs are fired when there is no designer created process running. One example of this is when a AppxODBC connection manipulates data that is stored in an Appx database.

3)FLEPs were designed to provide a place to code data specific rules, not process specific rules. If there is code that is specific to a process, code it in that process, not in the FLEP.

Some customers have come up with creative ways to bypass this restriction such as creating a permanent disk file with OS process ID as the key to write data into that they can later read in the FLEP. This is not recommended as a general programming technique for the reasons listed above.

[Append to This Answer]
2004-Mar-16 1:47pm
(Answer) (Category) FAQ's - APPX Software, Inc. : (Category) APPX Utility : (Category) APPX Development Environment : (Category) Data Dictionary :
How many times does Post-PCF Read FLEP fire?
I have an update/query combination in a job. While stepping thru the code, I noticed that APPX ran thru the Post PCF Read FLEP 4 times for the first record (it may do it for every record, but my test only had one record in it). Is there some reason for this?

Yes.
A query process returns every detail record once. If a PCF record triggers a range-start, it's returned twice. If a PCF record triggers two range-starts, it's returned three times (and so on). The same is true if a record triggers a range end.
So, detail records are processed once and range-start/range-end records are processed more than once.

A range start happens when you've sorted the PCF and Appx finds a new value in one of the sort keys. Just because you don't have a frame that executes at that range boundary doesn't mean that the range doesn't exist.
In other words, we detect the range start and range end boundaries regardless of whether your have range start and range end frames. Remember, you can use the same query invocation with multiple outputs.
If you remove all of the sorts, you'll still see two extra Post PCF Reads (for the unbounded range).
Appx isn't physically reading the record for each range boundary - it's just reporting the state change (by invoking the Post PCF Read).
[Append to This Answer]
2006-Mar-13 2:41pm
(Answer) (Category) FAQ's - APPX Software, Inc. : (Category) APPX Utility : (Category) APPX Development Environment : (Category) Data Dictionary :
Do many duplicate keys decrease the performance?
When you define a key (in the Appx data dictionary), you can choose from four key types:
    Primary
    Alternate/Unique
    Alternate
    Alternate/Forced
The last two types allow duplicate key values. When you create an Alternate/Forced key, Appx appends the primary key (for each record) to the end of the Alternate/Forced key.

There are two advantages to an Alternate/Forced key (and at least two disadvantages).

The first advantage is that you don't suffer the performance penalty usually associated with a long chain of duplicate key values (because you have no duplicate key values). The second (and typically more important) advantage is that, when you read along the Alternate/Forced key path, you get duplicate records in primary key order. Many applications assume that duplicate key values appear in primary key order.

The first problem with an Alternate/Forced key is that it takes more disk space to store the index and, therefore, more disk I/O to read and write the index - Appx must store the complete primary key for every record in the alternate index (along with the key segments that define the Alternate/Forced key). The second problem with an Alternate/Forced key comes from the fact that Appx limits keys to 16 segments - if you have a four-segment primary key, you can't define more than 12 segments in an Alternate/Forced key. That's not often a problem, but it can be difficult to work around when you run into it. Appx will coalesce adjacent string segments into a single segment to reduce the segment count so you run into the 16 segment limit less often than you might think.

Note that the on-line help text for Key Type states that an "Alternate/Forced key is identical to an Alternate key fields, except that duplicate alternate keys are retrieved in primary key order" - there's no guarantee there that you'll gain better performance by choosing an Alternate/Forced, we just promise to return records with duplicate key values in a specific order. The mechanisms that we use may (and in fact do) vary by file type (AppxIO vs. Oracle vs. DB2, etc.
It just so happens that an Alternate/Forced key performs better than an Alternate key (at least for AppxIO files). In fact, AppxIO treats every Alternate key the same way it treats Alternate/Forced keys. Appx may choose a different method to improve the performance of duplicate indexes in the future - so, if your application requires that duplicate key values appear in primary key order, be sure to choose Alternate/Forced: you'll get record in the order that you expect and you'll get better performance (in most cases).

[Append to This Answer]
2005-Jun-01 9:22am
(Answer) (Category) FAQ's - APPX Software, Inc. : (Category) APPX Utility : (Category) APPX Development Environment : (Category) Data Dictionary :
Can ERROR statement be used in FLEP's?
ERROR statements can be useful in some FLEP's, but you have to remember that Appx may execute the FLEP's in contexts where a user can't see the message.
If you execute an ERROR in the PrePCF Update event point, you cancel the WRITE, REWRITE, or DELETE that caused the event point to fire.
WARNING and MESSAGE statements in an FLEP seem fishy to me - I'd rethink any of those that I ran across.
[Append to This Answer]
2005-Jun-28 3:33pm
(Answer) (Category) FAQ's - APPX Software, Inc. : (Category) APPX Utility : (Category) APPX Development Environment : (Category) Data Dictionary :
FLEP questions
If I have a FLEP for file "A", and in that FLEP I read file "X", will the record buffer for the calling process for file "X" be changed (if it uses file "X"), or does the calling process have it's own record buffer for ""X"? I realize that if I change file "A", the calling process will see the change, I'm just wondering if that applies to all files I use in the FLEP.

Each "stream" has it's own set of variables (not just the record buffer, but PDF's, readnext positions, ....).

[Append to This Answer]
2005-Aug-24 9:21am
(Answer) (Category) FAQ's - APPX Software, Inc. : (Category) APPX Utility : (Category) APPX Development Environment : (Category) Data Dictionary :
I want to delete fields from a file in my DD, but those fields contain data, should i delete the data first?
No, you don't need to delete your data first. When you delete the fields and run Restructure, the data in the deleted fields will be deleted as well.
[Append to This Answer]
2006-Feb-24 4:15pm
(Answer) (Category) FAQ's - APPX Software, Inc. : (Category) APPX Utility : (Category) APPX Development Environment : (Category) Data Dictionary :
I added a new value to a validation table and it’s not listed at run-time, why?
This is a bug. Validation table values are cached at the workstation and the Java client is not recognizing that a change has occurred. As such, the cache is not updated. The temporary workaround for this it to delete the folder .appx\cache\x where x it the server name on the users workstation. The .appx directory is normally found in Documents and Settings for the users. Exit and restart the Appx session and the update validation table should contain the new value(s).
[Append to This Answer]
2010-Mar-23 3:54pm
Previous: (Category) Subroutine Processes
Next: (Category) Other Application Design Questions
This document is: http://board.appx.com/cgi-bin/fom.cgi?file=33
[Search] [Appearance] [Show Top Category Only]
This is a Faq-O-Matic 2.719.
Copyright 2003 by APPX Software, Inc. All rights reserved.