Edit form

1. General information

• An edit form is a graphical interface used to work with a single database record. It is used either to create a new record in the database or to edit an existing one.
• Each edit form has exactly one associated database table that stores the user data entered in the form. Its actual name is defined by the form identifier. Identifiers of user-defined forms normally start with the “ng_” prefix; system forms do not use this prefix.
• The structure of a standard associated database table is created and subsequently maintained automatically from the edit form and control configuration. Manually maintained database structures, such as the In-Memory tables and database views described below, are exceptions.
• Each associated database table contains a set of system database columns that form the foundation of the application logic:
  • “id” – the primary key of the database record, with the data type “int NOT NULL” or “long NOT NULL” depending on the form configuration.
  • “system” – a system record flag. The value “True” indicates a record that cannot be deleted (for example, system user records in NET Genium).
  • “pid” – the identifier of the parent database record, used for hierarchical relationships.
  • “pform” – the identifier of the edit form in which the parent record is located.
  • “userid” – the identifier of the user who created the database record and is its owner.

1.1. Edit form controls

• An edit form consists of database controls and visual controls.
  • A database control is always associated with a single column in the underlying database table, into which values entered by the user are stored. To be meaningful, an edit form must contain at least one database control.
  • Visual controls do not have a database column of their own. They are used for presentation, navigation, or interaction and may run scripts or operations that create, modify, or delete other database records. These include headings, data grids, buttons, graphical separators, and other decorative elements.
  • Every edit form automatically contains the “ActionButtons” control, which provides three essential buttons: “Save”, “Delete”, and “Back”. A detailed description of this control is available in a separate guide Edit form – ActionButtons.
• Controls in an edit form are typically arranged vertically but may also be visually organized into multiple columns using control anchoring. Users can navigate between database controls using the “TAB” key to move forward and “SHIFT+TAB” to move backward.
• Edit form controls can be accessed via JavaScript to dynamically change their properties, behavior, or values. For database controls, it is possible to read and set values of text fields, drop-down lists, and similar elements, provided that the control identifier in the HTML object model is known.

1.2. Permissions to enter an edit form

• An edit form is usually opened through navigation elements located on view pages or within other edit forms. A user can also be redirected to it by a server function (“SCHEDULEFORM”) or an external function. The form can also be opened through the direct URL “Form.aspx?form=<form ID>&id=<record ID>”, so security must never rely on hiding the URL; display and editing remain subject to permissions, ownership, and record locking.
• To create a new database record, a user can open an edit form in several ways:
  • Using a button placed on a view page or another edit form that redirects the user to a specific edit form. This is configured in the properties of the “Button” control or in its script using the “SCHEDULEFORM” function.
  • Via a view table that displays data from the edit form. This option is enabled by allowing the “New record...” icon in the view table settings.
  • Through other visual controls such as calendars, multi-resource planners, timetables, Gantt charts, or tree structures, provided that creating new records is enabled in their configuration.
  • By direct navigation from a view page that is configured to redirect the user to a specific edit form.
• To edit an existing database record, a user can open an edit form:
  • By clicking the pencil icon in a view table.
  • Through visual controls that allow opening record details, such as clicking an item in a calendar, map, Gantt chart, or tree structure.
  • Using a button with a “SCHEDULEFORM” script that opens a specific database record.
  • Via a view page configured to always open the first record of a given edit form.

1.3. Permissions to display edit form content

• An edit form itself does not have an independent display permission. Its visibility is determined by the permissions of its internal controls.
• An edit form displays only the controls to which the currently logged-in user has access. If the anonymous user has access to no control, the login screen is displayed instead of the form; a logged-in user gets an empty form in such a case.
• Each control can define specific user groups or individual users who are allowed to see and use it. Other users will not see the control and cannot interact with it.
• A control without any configured permissions is visible only to users with administrator rights – permissions of the edit form or the application are not inherited.
• If a user creates a new database record without having permission to some database controls, the corresponding database columns will be stored with the value “null”.
• When an existing record is saved, values of database controls for which the user has no permission are not overwritten and remain unchanged.

1.4. Record ownership

• Each database table contains a “userid” column that stores the identifier of the user who created the database record and is considered its owner.
• By default, the owner of a new record is the signed-in user who saves the record in the edit form. JavaScript of the edit form can change the owner of a new record before it is saved – the “#owner#” variable returns a reference to the hidden field with the ID of the record owner. For an existing record, the owner is always read from the database and a change of this field has no effect.
• Database records that were imported or created by an external application may not have the “userid” value set. Such records are considered to have no owner.
• The owner of an unowned record becomes the user who first opens the record in an edit form and saves it.
• When opened, an unowned record is treated as a record of the currently logged-in user. If “Editing rights” is set to “Owner or co-owner of the record”, any user with access to the controls of the form can therefore edit and save such a record.
• Only saving the record in an edit form sets its owner. Bulk changes and bulk deletion in a view table treat an unowned record as someone else's record; editing a value directly in a view table cell behaves the same as in the edit form.
• The anonymous user has a single user account “Anonymous” in NET Genium, so a record created by an anonymous user is owned by this account and, from the ownership perspective, belongs to all anonymous visitors. For public forms, it is advisable to keep “Editing rights” set to “Co-owner of the record only” and to add the users who process the records to the co-owners.

1.5. Record co-ownership

• In addition to a single owner, database records may have one or more co-owners.
• Co-owners can be individual users or entire user groups.
• Co-ownership is not defined per individual record but at the level of the database table, i.e., the edit form as a whole.
• Ownership or at least co-ownership is required to edit and save an existing database record; the exact behavior is controlled by the “Editing rights” setting.
• If a user is neither the owner nor a co-owner of a record, they are not allowed to modify it. A user with administrator rights is an exception.
• Co-ownership has no effect on the creation of new records. The owner of a newly created record is the user who saves it in the edit form, unless JavaScript of the form changes it (see “Record ownership”).

1.6. Permissions to display control values

• Visibility of database control values may be governed by record ownership or co-ownership.
• The permission to display a control value is configured directly in the properties of the control.
• A control can be configured in one of the following ways:
  • the value is visible to all users (default),
  • the value is visible only to the owner or co-owner of the record.
• In an edit form, a control whose value is visible only to the owner or co-owner is displayed to whoever may edit the record – a user with administrator rights, a co-owner, and the owner if “Editing rights” is set to “Owner or co-owner of the record”. Other users do not see the control and cannot view or enter its value.
• Such a control cannot be displayed as a view table column and is not exported from a view table. In view table details, in a tree, and in a kanban, its value is displayed to the owner and co-owner of the record, and for an unowned record to all users. A print template always prints the value.
• The setting protects the display of the control, not the value used in the page code: a control identifier used in JavaScript or in the “HTML” control is replaced with the value from the database for a user who cannot see the control.

1.7. Permissions to save a record

• Permission to save a database record requires rights to at least one database control and ownership permission according to the “Editing rights” setting. An administrator may save the record outside this ownership limitation.
• Edit permission is configured directly in the properties of the edit form.
• An edit form can be configured in one of the following modes:
  • both the owner and co-owner are allowed to edit,
  • only the co-owner is allowed to edit (default setting).
• Scripts of buttons and events of the edit form write to the database regardless of the permissions of the user who ran them – who may perform the action is determined by the permissions of the button.

1.8. Permissions to delete a record

• Only an existing non-system record may be deleted, and only when the user is allowed to edit the form and has access to at least one database control in it.
• By default, the user must have permission for all database controls in the edit form.
• If the “Always allow deleting to the owner or co-owner of the record” option is enabled in the “ActionButtons” control, an authorized owner or co-owner may delete the record even without permission for some database controls.
• A record with the “system” flag cannot be deleted even when this option is enabled.
• If the user is not allowed to delete the record, the “Delete” button is inactive. For a new record that has not been saved yet, the “Delete” button is always inactive.
• Deleting a record deletes neither its nested records nor the files of its attachments.

1.9. Control identifiers

• A control identifier represents a reference to a database control in the HTML object model and simultaneously defines the name of the database column where the entered values are stored.
• The identifier is derived from the control name and starts with the prefix “ng_”. System controls do not use the “ng_” prefix.
• The control identifier is available on the “Administration” tab in the control properties.
• Identifiers can be used:
  • in JavaScript executed in the web browser,
  • in server-side scripts,
  • in database conditions and joins,
  • in the “HTML” control,
  • in print templates.

1.10. Record locking

• Database records opened in an edit form can be locked so that only one user can edit them at a time.
• The user who opens a record first and is allowed to modify it automatically locks it.
• The lock is automatically renewed while the user is working in the edit form. It is released immediately when the user leaves through the “Back” button or a form redirect; if the browser tab is closed, the browser crashes, or the connection is lost, the lock expires after the configured period from its last renewal.
• The lock duration is configured in minutes in the edit form settings and is primarily relevant in case of technical issues such as browser tab closure or connection loss.
• Locked records are indicated in view tables by a lock icon showing who locked the record and until when the lock is valid.
• Locked records can still be opened by other users, but the edit form is displayed in read-only mode.
• A user with administrator rights does not respect the lock of another user – they can edit and save a locked record.
• The anonymous user does not lock records, but the lock of another user applies to them.
• The record is locked only if the user has rights to at least one control of the form and is allowed to modify the record. A user for whom the form opens as read-only (without the right to modify the record or to any database control, or with the record locked by another user) does not lock the record; a lock held by another user is reported to them, though. If the form is disabled only by the “OnAfterOpen” event script with the “DISABLEFORM” function, the record is locked in the same way as in a form that can be modified.
• The lock applies only in the edit form. Editing a value directly in a view table, bulk changes, data import, scripts, and the “form_Save” and “control_Save” functions write even to a record locked by another user.

1.11. History and change tracking

• Each edit form has an automatically generated history database table named “<form identifier>_history”.
• The history table contains copies of the form's user-defined database columns and its own system columns:
  • “id” – history record ID,
  • “date” – date of the change,
  • “userid” – login name of the user who performed the change,
  • “action” – identifier of the change source, such as a script, button, or service; changes written by a data import into a view table, by synchronization or by a restore from history leave it empty; for changes that did not go through submitting the edit form, it holds the value:
    • “ngef.aspx” – a change made by an external function called from JavaScript,
    • “Save.aspx” – a change saved without submitting the edit form: by editing a value directly in the view table, by the “form_Save” and “control_Save” JavaScript functions, or from a matrix,
  • “changedid” – identifier of the affected record,
  • “pform” and “pid” – parent relationship of the affected record (part of the snapshot used to restore a deleted record),
  • “userid2” – owner of the affected record, stored separately from the change author in “userid” (used to restore a deleted record),
  • “created” – record creation flag (“x” = created via form, script, external function, MCP server or synchronization, “i” = via data import into a view table, “r” = restored from history),
  • “deleted” – record deletion flag (“x” = deleted, “r” = deletion reverted by restore).
• When a record is created, the values of user-defined columns are stored in history in the same way as in the main database table.
• When an existing record is updated, only changed user-defined columns are stored in the history row. Columns that were not changed by that particular update remain without a stored value in the history row (database value “null”).
• If a field value is changed to database NULL, NET Genium stores it in history using an internal placeholder value according to the column data type, so it can be distinguished from a column that was not changed at all.
• When a record is deleted, the last values of user-defined columns are stored in history — this full snapshot enables later restoration of the deleted record.
• When history is displayed, some special stored values are shown as three dots “...” with a tooltip that determines their meaning: “Empty string” means changing a text field to a zero-length text string, “Database value NULL” means changing the field to database NULL, and “ID 0” or tooltip “0” means a stored zero value, typically no selected record for a foreign key or no file/image for the corresponding controls. Three dots “...” by themselves therefore do not mean “unchanged”.
• When history logging is enabled, creating, updating, or deleting a database record generates a corresponding history entry. An update that does not change any value creates no history entry.
• Changes made by the “DELETEDATA” server function, by the “TRUNCATE TABLE” commands in the edit form settings, deletions via the MCP server, writes via the MCP server without history enabled and direct changes in the database are not written to history.
• Restoring a deleted record from history creates a new history entry with the “created” flag set to “r”, and the original deletion entry gets the “deleted” flag set to “r”. The restore is written to history even for an edit form with history logging disabled. If a record with the same ID exists in the database table, the restore is not performed.
• History logging is enabled by default and can be disabled in the edit form settings.

1.12. Database table synchronization

• Synchronization is used to maintain consistent copies of database tables across multiple NET Genium installations.
• Both one-way and two-way (multiple master) synchronization are supported.
• In two-way synchronization, changes are applied in the same order in which they were initiated on the source server.
• Synchronization is not available in NET Genium Online – the link to its settings is not displayed in the edit form menu.
• Changes are not forwarded: a change received from another installation is not sent anywhere else. If a record is to get from server A via server B to server C, server A has to be linked directly to server C as well.
• Changes wait in a queue shared by all forms and all linked servers and are sent strictly in the order in which they were made. If a change cannot be sent (unreachable server, missing form on the remote side, database error), the transfer of all further changes stops until the cause is removed or until the change is deleted from the queue in the synchronization report. The next attempt takes place after 2 minutes at the earliest.
• A record has the same ID in all synchronized installations. A new record therefore gets an ID agreed with all remote sides before it is sent, and is renumbered locally if necessary.
• Foreign keys, the link to the parent record (“pid”) and the record owner are transferred as numbers, so the referenced records must have the same ID in all installations. The record owner is transferred only if users (the “User” form) are synchronized to the same server as well. The parent form of nested records must be linked to the same server.
• Attachment files are transferred together with the record and a new attachment is always created on the remote side. If the attachment file is missing on the sender's disk, the remote side keeps its original value.
• E-mails sent by the “OnBeforeSave” and “OnAfterSave” scripts of a synchronized record are sent only after the record has been successfully transferred to all remote sides.
• Deleting a record is transferred to the remote side, but only the record itself is deleted — neither nested records nor attachment files. A new record deleted before it was sent is not transferred to the remote side at all.
• Changes made by a data import into a view table, by restoring a record from history, by the “DELETEDATA” server function, by the “TRUNCATE TABLE” commands, by deleting via the MCP server and by writing via the MCP server without history enabled are not queued.
• In administrator mode, the edit form of a synchronized record offers the “Synchronize” button, which sends all synchronized columns of the current record.

2. List of tabs in the edit form settings dialog

• General – Setting general properties
• Other – Primary key settings, locks, change tracking and javascript
• Help – Set up floating help text and group controls
• Editing rights – Rights settings
• Rights of child objects – Setting the rights of child controls
• Administration – Setting other properties

2.1. “General” tab

2.1.1. Name

• The name of the edit form ideally determines the name of one database record, expressed in a single number, which is stored in the database table associated with the form.
• The name of the edit form is displayed in the title of the web browser tab.

2.1.2. Dictionary

• The dictionary displays a list of application group names, applications, categories, view pages, edit forms, and controls used throughout the application.
• The dictionary search is used to suggest the correct name for the edit form and to maintain the consistency of the nomenclature throughout the application.

2.1.3. Options

• Tab General + Other
  • Checking this box determines whether the “Tab” and “Other” tab controls should also be created when creating a new edit form.
• Change tracking + Watcher
  • Checking this box determines whether change tracking controls should also be created when creating a new edit form:
    • “History” control
    • “Watcher” control
      • Created by
      • Created on
      • Modified by
      • Modified on

2.1.4. Enter the columns of your new table

• The “Enter the columns of your new table” field enables the creation of new controls in the edit form.
• Individual column names are entered line by line, separated by the Enter key, each line represents one column of the table.
• A data type may be specified after the column name, written after a colon and a space immediately following the name:
  • string
    • Wizard button for quick selection of this type: Text string
    • Target control: TextBox
    • Data type: Text string
    • Width: 150 px
    • Maximum length: 100 characters
  • integer
    • Wizard button for quick selection of this type: Whole number
    • Target control: TextBox
    • Data type: Integer
    • Width: 150 px
    • Maximum length: 100 characters
    • Alignment: Left
  • double
    • Wizard button for quick selection of this type: Decimal number
    • Target control: TextBox
    • Data type: Decimal number
    • Width: 150 px
    • Maximum length: 100 characters
    • Alignment: Left
  • date
    • Wizard button for quick selection of this type: Date
    • Target control: TextBox
    • Data type: Date
    • Width: 150 px
    • Maximum length: 50 characters
  • file
    • Wizard button for quick selection of this type: File
    • Target control: File
  • image
    • Wizard button for quick selection of this type: Image
    • Target control: Image
• Specifying a data type is optional; if no data type is provided, the default type is string.

2.1.5. Add new columns

• New columns can be added to an already created and saved editing form by checking the “Add new columns” option.

• The names of the new columns are entered into the “Enter new columns” field, with each line representing one column.

• The placement of inserted controls in the form is governed by whether a specific position is marked before editing the editing form, or before pressing the gear icon:
  • Without marking – inserting controls at the end of the editing form; if the last control of the form is the “Space” graphic separator, the controls are inserted before it
  • With marking of the location using a horizontal line – inserting controls at a predetermined position

2.2. “Other” tab

2.2.1. Primary key

• The primary key specifies the data type of the primary key – the database column “id”, which is part of every database table in NET Genium.
• The data type of the primary key can be changed from Integer to Long at any time.
• A reverse change from Long to Integer is performed only if all primary key values in the database table and in the history table fall within the range of the Integer data type; otherwise the primary key remains Long. A confirmation is requested before the change, because the data conversion may take a long time.
• Before changing the primary key to Long, it is important to ensure that external functions, services, or other applications that work with the database table function properly. These are mainly DataSaver or DataSaverSynchro objects that must be changed to DataSaver2 and DataSaverSynchro2.

2.2.2. Record locking

• Database records opened in the edit form can be set so that only one user can edit them at a time.
• The user who opens the database record first and is allowed to modify it automatically locks the record. While working in the edit form, the lock is automatically extended. It is released immediately when the user leaves through the “Back” button or a form redirect; if the browser tab is closed, the browser crashes, or the connection is lost, the lock expires after the configured interval from its last extension.
• The lock belongs to the web browser window in which the record was opened. If the same user opens the record in another browser as well, the edit form is shown there read-only, just as it is to other users. If the user opens it in another window of the same browser, the form is blocked right after opening, just as when the lock is taken over as described below, and a message says so. In both cases the tooltip of the lock icon in the view table tells the user that the record is open elsewhere. A lock left behind by a closed window is released for the other windows of the same login, too, only after the configured time interval has elapsed.
• If another window or another user takes over the lock in the meantime, typically after the lock expired while the computer was asleep, the original window detects it at the next automatic lock extension, says so in a message and blocks any further editing of the record in it: it disables the buttons for saving and deleting the record as well as all buttons of the edit form controls, disables mass editing in the view tables of the form and turns off autosave. The “Back” button keeps working. The server checks the lock when the record is saved or deleted as well, so neither goes through from such a window even if the user attempts it before the window detects the takeover; a message about the locked record is shown instead.
• Record locking is defined in the edit form settings by specifying a time interval in minutes during which the lock should be active. The length of the time interval plays a role only in case of technical problems of the user, due to which the lock cannot be extended automatically during the entire time the user works with the database record in the edit form. Typical issues include opening a different web browser tab, closing the current tab with a cross, launching a different application on a mobile phone, or internet outages. Therefore, in case of technical problems, the lock will not be released automatically until a selected time interval has elapsed since the last automatic lock extension. The length of the time interval therefore determines the period for which the lock will be active even in the event of a connection failure between the client and the server.
• Restarting the web application releases all locks (with multiple instances over one database only the restart of the main instance; the other instances release them no sooner than 6 hours after the previous restart). Logging out a session by an administrator or a user account administrator releases the locks of that session immediately; a regular logout or session expiry does not release the locks – they expire only after the configured time interval has elapsed.
• Locked records have a lock icon in the view table instead of the pencil icon that is used to open the database record. The lock icon contains a tooltip with information about who locked the record and until when the lock is active. Even so, the database record can still be opened using the lock icon; other users can only read the edit form with the locked record without editing it.

2.2.3. Options

• Log opening records
  • Checking this box determines whether each opening of a database record in the edit form should be recorded in the change tracking history.
  • A history record is created on every opening of an existing record, even if the user does not save the record.
  • Opening is logged only if history logging of records is not disabled and the user has rights to at least one control of the edit form.
• Disable history of records
  • Checking this box determines whether database record history logging should be disabled.
  • Disabling the logging completely, or even temporarily, is recommended before bulk editing or deleting database records, where each change or deletion of a database record creates one record in the change tracking history.
  • Disabling the logging applies only to new changes; previously written history records are kept.
• Disable JavaScript
  • Checking this box determines whether to disable the generation of the content of “JavaScript” controls. In addition, the event code of “CheckBox” controls that calls the “chb_Display” function is not run when the form is opened, and the button for clearing the value of “TextBox” and “ForeignKey” controls is displayed as a button instead of an icon.
  • JavaScript in the events of controls and in the “Client” field of buttons is not disabled by this setting.
  • The JavaScript of the “ActionButtons” control buttons (“Save”, “Delete”, “Back”) is not disabled by this setting.
  • This option is used in situations where the edit form is looped by inappropriate javascript. In some cases, it is not even possible to open the edit form settings in the usual way, and it is necessary to use reports to do so. A detailed description of the reports is provided in the separate guide Reports.

2.3. “Help” tab

2.3.1. Width of floating help

• The width of the floating help determines the width of the help box for the edit form located in the upper right corner of the form. This box is displayed independently of the vertical scroll in the edit form.
• The floating box also includes the contents of all “RichText” and “HTML” controls with the “Floating help in edit form” check box selected. This content is located behind the help of the edit form in the order that these controls have in the edit form.
• If the width is not filled, the default width of the floating box of 200 pixels is used.

2.3.2. Options

• Automatic grouping
  • If “Automatic grouping” is checked, a bulleted list of all help controls located on the same row will be automatically generated in the help column of each edit form control, with the option to click the bulleted list item and display the help text.
  • If “Automatic grouping” is not checked, the help for controls to the left of snap-on controls is not displayed.
  • Help grouping is used for controls that have the “Snap to previous control” check box selected.

2.3.3. Help

• Help is the text displayed in the upper right corner of the edit form inside the floating box.
• The floating box also includes the contents of all “RichText” and “HTML” controls with the “Floating help in edit form” check box selected. This content is located behind the help of the edit form in the order that these controls have in the edit form.

2.3.4. Notes

• Notes are used to enter any text intended for the application administrator.
• Calls to server functions that control the behavior of the edit form are placed in the notes:
  • CENTER() – centers the edit form
  • DISABLEAUTOFILL() – prevents the web browser from filling in text fields automatically
  • DISABLEPAGETOOLS() – hides the icons in the upper right corner of the form
  • FULLAJAXMODE() – the form uses ajax requests instead of submitting the form
  • LABELSINSIDE() – controls display their label inside the control
  • LAYOUT(id) – uses a different layout for the form
  • LEFTALIGNMENT() – aligns the names of controls in the left column to the left
  • LOWRESOLUTION() – displays the form on a mobile device for a small screen
  • MARGINS(top, right, bottom, left) – sets the margins of the form
  • NOBACKGROUND() – controls do not use the colored background of the left column with names
  • WEBFORM() – controls use the reverse design of a web form without the colored background of the left column
• Only the listed functions are evaluated from the notes when the form is opened; the rest of the notes, including other server functions, is not evaluated. A detailed description of server functions is provided in the separate guide Server functions.
• The text “DEBUGPICKER” in the notes turns on writing the progress of taking over values from the picker to the browser console. A detailed description of the picker is provided in the separate guide Picker.
• The definition of the database view is placed in the notes if the edit form is set to read data from the database view.

2.4. “Editing rights” tab

2.4.1. Co-owners of the records

• Record co-owners define a list of user groups and users who extend ownership of database records. In addition to the owner of the record, i.e. the user who created the database record, they extend ownership by other users who automatically become co-owners of all records in the database table.

2.4.2. Editing rights – options

• Owner or co-owner of the record – database records in the edit form can be edited by the owner or co-owner of the record.
• Co-owner of the record only – database records in the edit form can be edited only by the co-owner of the record.
• A user with administrator rights may edit the record regardless of the “Editing rights” setting.

2.5. “Rights of child objects” tab

• Rights define a list of user groups and users who have permission to display controls on an edit form and to display the values of those controls elsewhere in the application.
• The edit form has no separate display permission. It opens for a user who has permission to at least one of its controls; controls without permission are not displayed in the form.

2.5.1. Options

• Replace rights in all child objects - Checking this box determines whether the rights settings in all child controls should be overwritten to the same permissions as those set in the edit form itself when the edit form is saved.
• Add selected rights to all child objects - Checking this box determines whether all selected user groups and users should be added to all child controls when saving the edit form.
• Remove selected rights in all child objects - Checking this box determines whether all selected user groups and users should be removed from all child controls when saving the edit form.

2.6. “Administration” tab

2.6.1. Location

• Select the application in which the edit form is located.
• The drop-down list contains all applications.
• Edit forms located in the “Settings” system application may not be moved or deleted.

2.6.2. Identifier

• The identifier specifies the name of the database table in the database in which the user data filled in by the user in the edit form is stored.
• The identifier is derived from the name of the edit form. It starts with the prefix “ng_”, and also contains the alphanumeric characters used in the edit form name (system edit forms do not contain “ng_”). When changing the name of the edit form, the “Correct” button is available, which is used to correct the identifier and thus rename the database table in the database. For clarity and elimination of possible misunderstandings, it is recommended to keep the identifier in accordance with the name of the edit form. If external applications also access the database and, for example, read or write data to the database table of this edit form, it is necessary to schedule the change of the identifier until a suitable time.
• The “Correct all” button is available to automatically correct the identifiers of all database controls of the edit form.
• When the identifier is changed, its occurrences in the SQL, SQLARRAY, COLORLEGEND and EXPORTDATA server functions are corrected automatically. Occurrences in HTML and JavaScript controls, in print templates and in external functions are not corrected and must be edited manually.
• Read/write data from the database table using a memory optimized table
• For SQL Server only
  • In-Memory tables are database tables located in the operational memory, which are suitable for frequent writing of data – especially for creating new records (INSERT) or updating existing ones (UPDATE).
  • In-Memory tables are not suitable for troubleshooting database query processing speed while reading data (SELECT). The solution to these problems is always to set the indexes correctly.
  • Checking this box determines whether a database table with the same identifier as the edit form should be used to read and write data, with only the word “_memory” at the end of the name.
  • In-Memory tables must be created manually. For this purpose, it is possible to use the command “CREATE ng_book_memory” from the drop-down list located below the check box. This command displays a database query to create a new In-Memory table with the same structure as the edit form, and attempts to create the database table immediately.
  • In-Memory tables do not allow additional changes to the database structure. It is necessary to delete the old table first, and then create a new one with an updated structure. For this purpose, it is possible to use the command “DROP ng_book_memory” from the drop-down list located below the check box. This command displays a database query to delete an In-Memory table, and attempts to delete the database table immediately.
  • Before deleting In-Memory tables, it is important to back up the data stored in these tables, and then restore that data. For this purpose, it is possible to use the command “EXPORT DATA FROM ng_book_memory TO 'Backup\ng_book_memory.xml'” from the drop-down list located below the check box, followed by “IMPORT DATA TO ng_book_memory FROM 'Backup\ng_book_memory.xml'” or “IMPORT DATA TO ng_book_memory FROM ng_book“.
• Read data from the database table using a view
  • Checking this box determines whether a database view with the same identifier as the edit form should be used to read the data, with only the word “_view” at the end of the name. It is not possible to write data to views, so it is recommended to hide the “Save” button in these edit forms. An error occurs when trying to save data to a view.
  • Views must be created manually. For this purpose, it is possible to use the command “CREATE ng_book_view” from the drop-down list located below the check box.
    • This command displays a database query to create a new view with the same structure as the edit form, and attempts to create the database view immediately.
    • The view created by this command has the same structure as the edit form, and therefore it is necessary to modify its definition (CREATE VIEW) additionally.
    • It is advisable to save the resulting definition in a note of the edit form, where NET Genium will search for it the next time the “CREATE ng_book_view” command is run, and run it in this wording.
  • Views do not allow additional changes to the database structure. It is necessary to delete the old view first, and then create a new one with an updated structure. For this purpose, it is possible to use the command “DROP ng_book_view” from the drop-down list located below the check box. This command displays a database query to delete the view, and attempts to delete the database view immediately.
• In NET Genium Online neither the “Read/write data from the database table using an In-Memory table” nor the “Read data from the database table using a view” field is displayed – In-Memory tables and database views are not available in the cloud.

2.6.3. Commands

• CREATE REPORT FROM ng_book – Creating a report on the length of strings stored in the edit form
• CREATE ng_book_memory – Create In-Memory table
• IMPORT DATA TO ng_book_memory FROM 'Backup\ng_book_memory.xml' – Import data into In-Memory table from XML file located in the “Backup” directory
• IMPORT DATA TO ng_book_memory FROM ng_book – Import data into the In-Memory table from the main database table of the edit form
• EXPORT DATA FROM ng_book_memory TO 'Backup\ng_book_memory.xml' – Export of data from the In-Memory table to an XML file located in the “Backup” directory
• DROP ng_book_memory – Delete In-Memory table
• CREATE ng_book_view – Creating a view
• DROP ng_book_view – Delete view
• TRUNCATE TABLE ng_book + ng_book_history – Delete all data in the database table, including history records, and set the primary key counter to an initial value of 1
• TRUNCATE TABLE ng_book_history – Delete all history records, and set the primary key counter to an initial value of 1
• RECREATE TABLE ng_book + ng_book_history – Data backup and re-creation of database tables, including subsequent data import
• In NET Genium Online the drop-down list of commands is not displayed – none of the commands listed above is available in the cloud.

2.6.4. Index 1

• Setting the index to the “pid” database column or the associated index to the “pform” database column along with the “pid” column.

2.6.5. Index 2

• Setting the index to any list of database columns of the edit form.
• In the text box located below the check box, it is possible to define the names (identifiers) of all columns that are to be in the federated index – they should be part of the index key.

2.6.6. Delete history older than

• Setting the number of months during which it is necessary to keep the history of database records of this edit form.
• If the number of months is not filled in, the default setting of 6 months is used.
• The setting itself does not delete history automatically – older history records are deleted only in one of the ways listed below.
• Two buttons are located to the right of the text box:
  • The “Delete history” button permanently deletes the entire history of the edit form regardless of the set number of months.
  • The “older than” button deletes history records older than the number of months entered in the text box (6 months if not entered).
• History records older than the time period set in this way can also be deleted once using:
  • Smaller icons for deleting record history from reports. A detailed description of the reports is given in a separate manual Reports.
  • “DELETEHISTORY” server functions.

2.6.7. C#/JavaScript

• Using the “C#/JavaScript” button, a text report will be displayed with an example in C# for saving the record to the database table associated with this edit form.
• The report includes a list of all database controls in the edit form.

2.6.8. Statistics

• The statistics display aggregated information on the use of the edit form across the entire application.
• Using the “Statistics” button, a detailed report of all places where the edit form is used or referenced is displayed, including the option to open the settings of such a place or control.
• Before each deletion of the edit form, it is recommended to thoroughly go through the statistics of the editing element, and to eliminate possible misunderstandings.
• Before each deletion of the edit form, the evaluation of the statistics starts automatically. If the edit form is used or referenced somewhere in the application, it is necessary to confirm the deletion of the edit form again.

2.6.9. Logging

• Using the “Logging” button displays a detailed report containing records of the edit-form activity. The report includes information on:
  • the date and time when the edit form was displayed,
  • the user who displayed the edit form,
  • the processing time of the edit form,
  • the start date and time of the processing,
  • the end date and time of the processing,
  • the size of the resulting HTML code generated for the edit form,
  • an indication of whether it was the first form load or a form refresh (postback).

• For logging to function correctly, logging must be enabled in the NET Genium settings on the “Other” tab, either as “To database” or “To database and disk”. A detailed description is provided in the separate guide NET Genium settings.
• The minimum display time for processing an edit form is set to 0 milliseconds by default, so all display records of edit forms are displayed, including those whose processing took 0 milliseconds. This minimum time can be increased or decreased by changing the “mintime” parameter in the report URL.
• The number of records is limited to 100 by default. This number can be manually increased or decreased by changing the “maxrows” parameter in the report URL.

2.6.10. History

• Using the “History” button, a detailed report with individual change tracking records is displayed.

2.7. “Save”, “Delete” and “Close” buttons

• “Save” button – Save changes to the edit form settings.
• “Delete” button – Permanently delete the edit form. The edit form is deleted with all its controls, their database queries and scripts, the database table and the history table. The files of attachments stored in the form are not deleted. A system edit form cannot be deleted.
• “Close” button – Close the edit form settings dialog without saving changes.

3. Sync settings

3.1. Server settings

3.1.1. Name

• The name of the remote server, resp. NET Genium.

3.1.2. URL

• Internet address of the remote NET Genium (SSL communication via the “https” protocol can be used).

3.1.3. Synchronization password

• Synchronization password set on the remote NET Genium in the NET Genium settings.

3.1.4. Intranet URL

• Intranet address of the remote NET Genium, to whose records users will be routed from e-mail messages sent by the script.

3.1.5. Language

• The language in which links will be created in e-mail messages, directing users to NET Genium entries.

3.1.6. Options

• Ignore SSL errors
  • Checking this box determines whether errors in SSL certificates will be ignored when communicating with remote NET Genium via the “https” protocol.
• Proxy Server
  • Checking this box determines whether a Proxy Server will be used to communicate with the remote NET Genium.
• Proxy URL
  • Proxy Server Address.
• Login name
  • Login name for communication with the Proxy Server.
• Password
  • Password for communication with the Proxy Server.

3.2. Sync settings

3.2.1. Server

• The name of the server with which the data from the database table of the currently open edit form will be synchronized.

3.2.2. Edit form

• Edit form in the remote NET Genium, with which the data from the database table of the currently open edit form will be synchronized.

3.2.3. Condition for synchronization

• A condition that limits the scope of synchronized data to a specific set only.
• The condition is evaluated on every save of a record, including editing a value in a view table, mass changes and one-time synchronization. A condition on a script variable is considered satisfied outside a script (for example when editing a value in a view table).
• The condition does not apply to deleting a record. A record that stops satisfying the condition remains on the remote side.

3.2.4. Columns

• The column settings determine which column (left) of the remote edit form will be synchronized, and which column (right) in the currently open edit form.
• Each column can contain a condition only when the value of the column will be synchronized.

3.3. One-time synchronization of all data

• One-time synchronization sends all records of the database table with all synchronized columns under their IDs; it overwrites a record with the same ID on the remote side and does not delete records on the remote side that do not exist on the source.
• A maximum limit of 10,000 records is set for one-time synchronization. If it is exceeded, nothing is sent. The limit can be increased using the “MaxSyncCount.txt” configuration file. A detailed description of configuration files is provided in the separate guide NET Genium settings.

4. Edit form behaviour

4.1. Opening a record

• When a new record is opened, default values are filled in the controls. For an existing record, only the default values of controls with the “Fill in the default value every time the edit form is opened” option and the values of “AutoSum” controls are filled in.
• A required drop-down list and a required foreign key without a value get the first item of their offer when opened, even for an existing record.
• After opening, the “OnAfterOpen” script runs. Values the script saves with the SCHEDULESAVE server function and the recalculated values of “AutoSum” controls are written to the database already when the record is opened, without the user saving it.
• Opening a deleted or non-existent record redirects the user to a page informing about the deleted record.

4.2. Saving a record

• Saving a record proceeds in this order: *# validation of controls, including hidden controls and read-only controls, *# filling in the default values with the “Fill in the default value before every saving of the record to the database” option, *# the “OnBeforeSave” script, *# saving the record to the database, *# the “OnAfterSave” script, *# sending the e-mails scheduled in the scripts and the redirect scheduled in the “OnAfterSave” script.
• Only controls whose value has changed since the form was opened are saved to the database. If another user has meanwhile changed the same control, the value from the form overwrites it; only record locking protects against concurrent edits.
• The “Save” button saves the record and returns the user back. The “Save and new” button saves the record, runs the “OnBeforeOpen” script and opens a new record with the same link to the parent record. The “Save and continue editing” button saves the record and opens it again with the scroll position and the selected tab preserved.
• An error in the “OnBeforeSave” script does not save the record and the user stays in the form with the filled-in values. An error in the “OnAfterSave” script is displayed only after the redirect; the record remains saved.

4.3. Read-only form

• The edit form is displayed as read-only if the user is not allowed to edit the record (see “Editing rights”), if the record is locked by another user, or if the form contains no database control the user has access to.
• The values of controls sent from a read-only form are not used. Unless the reason is a lock of another user, buttons with a script that save the record work with the values stored in the database and with the values set by the script itself.
• If the record is locked by another user, a message about the locked record is shown after the form is opened, the buttons of the controls as well as mass editing in the view tables of the form are disabled, and the server rejects saving and deleting the record, including saving by the script of a button, with a message about the locked record.
• The “form_Save”, “control_Save” and “controls_Save” JavaScript functions do not save the record in a read-only form.

4.4. “Back” button

• The “Back” button as well as saving the record return the user to where the edit form was opened from, in this order: *# to the parent edit form with the scroll position and the selected tab preserved, if the record was opened from another edit form, *# to the picker, if the record was opened from it, *# to the main page with portlets, if the record was opened from a portlet, *# to the view page from which the record was opened, *# in admin mode to a new record of the same edit form, *# otherwise to the main page.

4.5. Errors, external functions and limits

• On every request to the edit form, the NETGenium.OpenForm external function runs. Its error ends the loading of the whole form. A detailed description is provided in the separate guide External functions.
• A script whose processing takes 60 seconds or longer is recorded in the “Scripts60sec” log.
• In the NET Genium Online cloud variant, the processing time of a single script is limited to 10 seconds; when exceeded, the script is interrupted with an error.

4.6. Copying an edit form

• A copy of an edit form is created by the copy icon in the navigation area in admin mode. The structure of the form, its controls, scripts, database queries, rights and co-owners are copied. Neither data nor synchronization settings are copied.
• A system edit form cannot be copied.