This is an old revision of the document!
This document describes the steps to configure Versago forms using the latest version form configuration tool, Forms (v2). The reader will find it helpful to read this documentation in its entirety as the configuration for v2 forms is considerably different from v1 forms provided in previous versions of Versago.
Special Notes Regarding Previous Versions of Versago Forms
This document is intended for Versago administrators. End-users do not have access to this function.
The following documents contain additional information that may be helpful with understanding these processes.
Forms (v2) is the second generation of Versago forms. Forms are used for user-entered data capture in the Versago environment.
v2 forms are not interchangeable with v1 forms. While some of the initial configuration process is similar, the underlying design functionality is quite different. When working with forms be sure to select the correct version of the configuration tool in the Administration menu.
The Forms maintenance tool provides two functions: creation of new forms and maintenance of existing forms.
Form Layout is the process of positioning fields for optimal end-user interaction. This process in v2 Forms is quite different than in previous versions. The form layout process is described here.
A form layout consists of rows as described above. Each row can consist of one to twelve columns. Form input controls are then placed (drag and drop) in the columns. The controls provide the mechanisms for data input presented to the end user. Form controls have various properties that define their presentation and behavior.
Control Types are discussed here.
Control Properties are discussed here.
Standard Buttons are discussed here.
The process of managing controls is discussed here.
Creating database tables using Versago is described in the following sections. However, keep in mind one key caveat:
The process described below can only be used to create tables. It cannot be used to modify an existing table. This must be done directly in SQL.
Database tables created using the Versago application use the “Quick Entry Form” function. This function is automatically displayed when the “Create New Table” option is selected as the Data Source for a new form.
Both Standard and Header/Detail forms will have a “header” table.
A table name is automatically generated from the form name by adding underscores in place of spaces. The table can be renamed at this point if desired. See the Detail Table section below for additional information when the form type is Header/Detail.
Data columns are added using the [+Add Field] button to open a new line in the grid.
| Field Name | Usage | Comments |
|---|---|---|
| vgoRecNum | Primary key | Required for any form table. Must be Numeric/Integer. |
| vgoCreatedBy | Email of user creating a new record | Should be included in any header form table |
| vgoCreateDate | Date a new record is created | Should be included in any header form table |
| vgoCreatedById | Versago User ID of user creating a new record | Should be included in any header form table. Used for reporting and profile access control |
| vgoLastModifiedBy | Email of user modifying an existing record | Only needed if records will be updated using the same form where they were created, and if change tracking is desired. |
| vgoLastModifiedDate | Date an existing record is modified | Only needed if records will be updated using the same form where they were created, and if change tracking is desired. |
| vgoLastModifiedById | Versago User ID of user modifying an existing record | Only needed if records will be updated using the same form where they were created, and if change tracking is desired. |
| vgoProcessStatus | “Flag” value to indicate if a record has been processed in some way (e.g. via Bizweaver) | Should typically be included in new tables. |
| vgoProcessDate | Date a record has been processed in some way (e.g. via Bizweaver) | Should typically be included in new tables. |
| vgoLinkID | Can be used to capture the ID of a record created in another system when the form record is processed in some way (e.g. Bizweaver) | |
| vgoLinkDate | Can be used to capture the date a record is created in another system when the form record is processed in some way (e.g. Bizweaver) | Like vgoProcessDate but used if two separate date stamps are desired. |
A detail table is only used when the form type is Header/Detail. The definition process is the same as shown for the header table. The only differences are the table name and the definition of the “key” column.
As noted in the Header section, a table name is automatically derived from the form name for the header table. The table name for the detail table must be entered manually. A good way to do this is to name the header table with “_Hdr” at the end. Then use the same name for the detail table except with “_Dtl” at the end. So, you might have tables “Demo_Form_Hdr” and “Demo_Form_Dtl”.
The detail table must have a ‘key” value that links back to the header table. This is named the “Linked Field.” The Linked Field must be the same name, data type, and format and the Primary Key in the header table.
The following images illustrate this setup.
In the detail table the column that links to the key value in the header is named “Linked Field.”
In some cases, you may want to create a table, or tables, directly in SQL. There is a specific way this needs to be done. The basic SQL statement are shown below.
Header Table
CREATE TABLE [dbo].[TestTable]( [vgoRecNum] [INT] NOT NULL, [vgoCreatedBy] [nvarchar](50) NULL, [vgoCreateDate] [datetime] NULL, [vgoCreatedById] [INT] NULL, -- Your columns here. Comma after the last column definition [Your_Last_Column] [Your_DataType], PRIMARY KEY CLUSTERED ( [vgoRecNum] ASC )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY] ) ON [PRIMARY]
Detail Table
CREATE TABLE [dbo].[Test_Table_Dtl]( [vgoRecNum] [INT] NULL, [LineNum] [INT] NULL, [ItemName] [nvarchar](100) NULL, [ItemCode] [nvarchar](50) NULL, -- Your columns here. **No comma after the last column definition** [Your_Last_Column] [Your_DataType] ) ON [PRIMARY]
To use these tables, select the “Existing Table” option for the Data Source. The application will determine the primary key value for the header table based on the table structure. You will need to identify the linked key value for the detail table as described in the “Create New Table” section above.
Lookups (also called Lookup List) are used when the list of values is extensive and is prone to change on a regular basis. An example where a lookup might be used is to show a list of customers. When a lookup list is used, the user can only select from these values, so consistency of input data is ensured. A field with a lookup list displays a “filter” indicator at the right end of the field.
Lookups use Versago reports as the data source. The report must exist before configuring the lookup list. See the “Versago Reports – Developer’s Guide” document for information on creating a Versago report. There are some basic rules for reports used for lookups.
In this example, we use a lookup to present a list of U.S. states. We want the user to select the state by name, but we want to capture both the name and the associated code.
In this example the value “Name” is placed in the Column (control) named “Lookup1” and the associated code is placed in the Column (control) named “Lookup2.”
Note that the controls that receive values do not need to be visible on the form. In this example the “Lookup2” is not displayed to the user even though the value is captured.
The configuration of a Dynamic DDL is more complicated than a Static DDL in that it uses a Versago report as the source for the list of values. It also allows values to be placed in other controls as needed.
Even though this DDL uses a report as its source for the list of values, the list of values should be relatively short. Having too many values in a DDL makes it difficult for the user to find the value they need.
In most cases, using a Lookup report instead of a Dynamic DDL is a better approach. The Lookup report provides some functionality, such as “search”, that the Dynamic DDL does not.
There are two types of Dynamic DDLs. The first type is like a Static DDL in that it only saves the value that is displayed to the in the database. The second displays one value to the user but saves a different value to the database.
An example of a “one value” Dynamic DDL might be a list of states that come from a database table. In this case the two-character state code is displayed to the user and is saved to the database.
An example of a “two value” Dynamic DDL might again be a list of states. But in this case, we display the full state name to the user for selection while the two-character state code needs to be saved with the Versago record.
Here are some basic rules for reports used for DDLs.
For the following examples we will use the same report in the two different ways. The two columns in the report are Code (the two-character code) and Name (the full name).
The [ …] button to the right of the Report selection drop-down can used to set up additional values to be captured and, if appropriate, the control(s) that provide input to any report parameters. This process is the same as described in Lookup Reports.
Custom form buttons are action buttons that are added to the form in the layout section. These are different from the standard Save, Save and Close, etc. buttons found on every form.
Actions from these buttons are treated as “pop-ups” by some browsers. You may need to change any pop-up block settings for your website to allow these functions to work correctly
A custom button can be used to let a user initiate a Bizweaver workflow from a Versago form. See the Invoking a Bizweaver Workflow Using POST page for full information on how to structure the call to the Bizweaver web service.
There are four types of default values that can be defined. These are static, user information, date, and header-to-row.
A static default value is simply a value that is used to fill in a field. The value can be a text value or a number.
Static values can also be used with drop-down lists. For example, assume you have a drop-down list for “status” with the values “Open” and “Complete.” When a user creates a new record, you want the value in the status field to be set to “Open.” Set the default value for the control to “Open” and the field will be populated. Be sure that the value you choose as the default is one that is included in the list of static values.
Note that the format and case of the User Information, Date, and header-to-row commands is critical.
“UserProfile” values are related to the current user. “Id” and “UserName” are typically captured to identify which user created the record.
This process can be used to use a value from a control in the header section as the default for a control in each new row in the grid (row) section.
Formulas can be used for a variety of purposes. Examples include calculating subtotals and totals, and doing date calculations. Details for creating formulas are found here.
Versago Custom procedures are SQL stored procedures that are executed every time a form action that interacts with the database occurs. This includes both Save (new and update) and Delete actions. Details of how to utilize these functions are found here.
Bizweaver is a companion product to Versago that is used for data management and integration. The processes that execute the work to be done are called workflows. A Bizweaver workflow can be initiated using a Versago form button action. This process uses a web service (API) provided by Bizweaver. The button can either be a standard form button (Save & Close, Save & New, Save, Delete) or a custom button.
A Bizweaver workflow is initiated using a POST transaction. Information on using this method is found here.
Any forms that were created using the v1 Form Builder tool will need to be rebuilt using the v2 Form Builder tool in order to use the POST functionality. v1 forms only allow use of the GET transaction, which is no longer supported.
Information on using this method is found here.
Read-only forms can be used to present the form information in its original format while preventing the user from making any changes. The easiest way to create a read-only form is to use the Clone a Form function. Once the original form has been cloned the new form can be changed as necessary. To make the form read-only, select the “Read Only” checkbox on the Form Setup page.
Keep in mind that a read-only form is an individual entity, even if it was created by cloning another form. A form created by cloning will not reflect changes made to the form from which it was cloned.
Files can be associated with, or “attached,” to a Versago form. The contents of an attached file is stored in a database table named TWBS_VGO_FormAttachments. This table is automatically created in any database where tables for forms are located. The file is converted to binary data and cannot be read directly from the table.
There are four key columns that are used when referencing records in the table:
In the following example, there are five “attachment” records.
| ID | ObjectID | RecordID |
|---|---|---|
| 1 | 10 | 1 |
| 2 | 10 | 2 |
| 3 | 10 | 2 |
| 4 | 12 | 1 |
| 5 | 12 | 1 |
“Attachment” files can be converted back to their original form and stored on disk using Bizweaver. Information on this process can be found here.