• Description
• How to use it
• 1. Accessing the CLI
• 2. Adding triggers to a table
• Implement trigger
• 3. Writing statements
• 4. Key mappings in b1 client in gitpod
• Further information
• CRC problems and solutions
• How field-rpos can affect CRC errors

Description

For development issues it’s sometimes necessary to enter the databases, which are included directly in a container of the workspace. For advanced settings, the way to enter the DB via the progress terminal tool is described afterwards

How to use it

1. Accessing the CLI

1. Enter build-one client orb1 client (which is the short form) into the terminal
2. You can cancel the login screen (by navigating with the arrow keys to <Cancel> and press enter

3. Now you see the menu and could normally navigate in the menu by clicking F3 but since we’re working in the browser this key input is interpreted differently and you have to use ESC + M, which has the same functionality as F3
4. Now you can navigate to Tools -> Data Dictionary

5. To choose a database, use Database -> Select Working Database

2. Adding triggers to a table

Define trigger in table

1. Choose a database and click Schema -> Modify Table
2. Choose a table
3. Navigate to <Trigger>using the arrow keys and Tab
4. Enter the filename of your to be created trigger in the action you want to use (in this example its the write statement) and adjust Overrideableand Check CRCas seen in the screenshot

5. Confirm with <OK>

Implement trigger

1. To implement a trigger navigate in the source tree to src -> backend -> DB -> Choose DB you would like -> trigger
2. Create a new file named exactly like defined in the trigger and implement there your logic in ABL

3. Writing statements

1. To write statements in ABL you can use the progress terminal tool directly
2. Below is an example, which gets all entries from tablename and display for each entry the field field1

FOR EACH tablename:
DISPLAY tablename.field1.
END.

To execute this command use normally F1 , escaping for that to use in browser would be CTRL + X

4. Key mappings in b1 client in gitpod

Further information

CRC problems and solutions

In OpenEdge, the field-rpos (field relative position) refers to the position of a field in a database table. When fields are added, deleted, or reordered in the schema, the field-rpos values may change, which can lead to differences between the schema the r-code was compiled against and the schema in the target database.

The r-code stores CRC checks for tables and fields, which include the field-rpos. If the field positions change between the time the r-code was compiled and when it's executed against another database (such as after a schema change or when loading a .df file), the CRC check fails, resulting in a CRC error.

How field-rpos can affect CRC errors

1. Schema Mismatch
1. If the schema loaded into DB2 (target database) has a different field-rpos from DB1 (source database) where the r-code was compiled, the CRC stored in the r-code will no longer match the schema in DB2, leading to CRC errors.
2. Field Reordering
1. If fields were reordered in DB1 (source) after the r-code was compiled, but the new schema was not loaded into DB2, the r-code might still expect the old field order. This will cause CRC errors, even if the field names and types are the same.
3. Adding/Deleting Fields
1. Adding or deleting fields in a table will shift the field-rpos of subsequent fields, causing a CRC mismatch unless the r-code is recompiled with the updated schema.

Back to Documentation

Back to Home Page