Basic Attributes

id

The id attribute of the Repeater module must be unique across all pages and forms in your job. That means duplicate names are not allowed, and if trying to name the repeater node the same as any other in the same job, RackForms will prompt you to create a different name.

Data Source

DB vendor

DB Host Name

DB Schema Name

DB User Name

DB Password

The password for this database connection.

DB DSN

This option is only used for ODBC connections. ODBC connections are extremely powerful, as they allow us to connect to virtually any database server in existence. So long as your database provider supports ODBC, you can connect and query it from RackForms.

ODBC connections can be made in one of two ways: Using a data source name, or using a direct connection string, often refereed to as a DSN-less connection.

Using a data source name:

At the most basic level, if we've set up a DSN in say, The ODBC Data Source Administrator application, this value can just be the DSN name.

For example, if we've created a data source name of: Production_Data, the value we place in this box is exactly that: Production_Data. The name alone suffices to point to the proper server and possibly connect, as the bulk of the connection details were defined when we created the data source.

Using a DSN-less Connection String

If we do not have a DSN, this value will be a driver definition block (connection string). The typical use-case here is when we do not have access to, or do not want the extra overhead of, creating and deploying DSN's on our client machines. Connection strings allow us to define the database properties "on the fly", which means the machine we're running on does not need to know about specific ODBC connections.

Connection strings take the form of name value pairs. The one gotcha often associated with these connection strings is the first element of the connection string must define which driver we're using.

For example, Microsoft Access would use:

Driver={Microsoft Access Driver (*.mdb)};Dbq=mdbFilename

SQL Server would be:

Driver={SQL Server Native Client 10.0};Server=server;Database=AdventureWorks;Trusted_Connection=yes;

The key here is the Driver={} part, the name between the braces must be the exact name of the ODBC driver loaded on your machine.

Finding this name is quite easy on Windows, simply load the ODBC Data Source Administrator application and click the Drivers tab. The value in the Name column is what we'll use. In we're running a Mac we can download ands use this tool.

Finally, even with a proper DSN or connection string, we may still have to define a DB User Name and DB Password. If at first you cannot connect, supply these two values and try the form again.

DB Connector File

If you input an absolute path into this box, RackForms will use that file for all database connection information for this query.

MySQL SSL Options

RackForms supports secure MySQL connections using SSL. To enable this functionality your MySQL Server will need to support SSL connections, which usually means modifying your servers my.cnf file to supply locations to your ca, server-cert, and server-key file. You may also, depending on your MySQL version, need to enable SSL connectivity. Learn more about this process and settings here.

As a very brief demo, the my.cnf settings we use internally are as follows:

ssl-ca=/mysql-ssl/ca.pem
ssl-cert=/mysql-ssl/server-cert.pem
ssl-key=/mysql-ssl/server-key.pem
ssl

Once the server has been configured to allow SSL connections, RackForms will need to know the location of three key files. These items are described below. To keep things simple, the names used in this document assume we've created our keys using the process described here. Please note the .PEM file locations can be relative or absolute.

MySQL Client Key File

The client key file will be called client-key.pem. This is our private key used in the SSL handshake process.

MySQL Client Certificate

The client certificate will be called client-cert.pem, and is used to publicly identify us using the CA file on record.

CA Cert

The last file will be called ca.pem, and is a "shared" file between the server and client, as in we use the same file.

As an example then, if I created a folder called mysql-ssl and placed my .PEM files within, the values I'd use in RackForms would be:

MySQL Client Key File - /mysql-ssl/client-key.pem
MySQL Client Certificate - /mysql-ssl/client-cert.pem
CA Cert - /mysql-ssl/ca.pem

Important Notes On MySQL and SSL Support

Using localhost: First, when using a localhost setup we'll often use localhost as our Database Host Name. The problem with this is on a local machine localhost uses sockets instead of TCP/IP, which means we're trying to encrypt a local communication channel. This simply doesn't work and we're receive a "doesn't support SSL/crypto" message. The solution here is to use 127.0.0.1 as our host name, which forces TCP/IP on a local connection.

Using Self-Signed Certificates: One common approach we may take when using SSL and MySQL for the first time is to set up a test instance on a localhost machine using self-signed certificates. This is great in concept but unfortunately creates some unique challenges. When we try and connect we may be greeted with the error:

SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

The problem here is new security features in PHP 5.6 and above, along with the MySQL native driver, creates verification issues when using self-signed certs. If this is the case we can disable certificate validation using the Verify MySQL SSL Server Cert option.

Verify MySQL SSL Server Cert

As noted above, when using self-signed certificates it may be necessary to disable certificate peer validation. This option should always be set to Yes in production environments, but if you have problems connecting on a local network or machine, try the No setting.

It's very important to note setting this to No completely defeats the purpose of using SSL, and should only be done on a non-production, local machine.

If you've made it this far we should only have one final consideration, the encryption cipher:

MySQL SSL Cipher

When connecting to a MySQL server using SSL, the client and server need to negotiate an encryption protocol and cipher. In the best case scenario this happens automatically, and the end result is the server automatically selects the most secure grouping possible.

Unfortunately this doesn't always work (especially when using self-signed certificates or builds of MySQL compiled against older versions of OpenSSL). The most common case is when your MySQL server only supports TLS V1, in which case the default cipher (DHE-RSA-AES128-GCM-SHA256), is not supported. If this happens you'll need to choose a different cipher from this list. The best way to do this is to start with the lowest value in the list, then work your way up until it fails again. Then, back down to the last working option.

The general rule will be if the default option fails, none of the 256-bit variants will work. This is usually considered a security issue, and you should take steps to update your MySQL server and/or PHP version to ones that support the latest security protocols.

SQL Repeater

Repeater SQL

Code Case
When writing our Repeater SQL code we'll want to use the convention of writing all SQL keywords in upper case. This is most important for the FROM keyword, but should be followed for all other keywords as well.

If we try and use a lower case from as in:

SELECT * from fb_demo

The editor will produce an error message prompting us to rewrite the SQL using an upper case FROM as in:

SELECT * FROM fb_demo.

Dynamic Variables
You can use dynamic variables in your Repeater SQL code, for example, if you have a page (page0.php) which can create a query string of: ./page1.php?id=1

When a user clicks this link, they will be taken to page1.php, which could be another Builder Repeater page. This page must then query the Database to retrieve the proper information for that particular variable.

Thus, we would create our Repeater node as normal, but in the Repeater SQL text area, we would add our dynamic variable to the query. We would create an SQL query that plucks the value of the _GET variable out like so:

SELECT * FROM cars WHERE id = " . $id ."

That said, it would be a VERY bad idea to use an un-sanitized GET or POST variable inline. Thus, for our example above we would use $id, which itself comes from a bit of defensive PHP Top Code:

<?php
$id = 0;
$valid = isset($_GET['id']) ? $_GET['id'] : false;
if($valid != false && is_numeric($_GET['id'])){
$id = $_GET['id'];
} else {
// can die() here, or other security measures.
}
?>

To see an example of this in action, please see the sample Builder job: defensive-security-measures.xml

Inline Encryption
MySQL Supports inline encryption using, among other functions, AES_ENCRYPT and AES_DECRYPT. We can use these function in our Repeater SQL calls so long as we're sure to alias the result to a standard field name. For example:

SELECT m_caseload.id,
AES_DECRYPT(m_caseload.name_first, 'bSg12YtshR#ws') AS name_first,
AES_DECRYPT(m_caseload.name_last, 'bSg12YtshR#ws') AS name_last,
m_caseload.active
FROM m_caseload

PHP Variables

_GET Variables

_POST Variables

$_SESSION Variables

F{form_field_name}

Security Concerns

Dynamic Variables

Complex SQL Considerations

Using * JOINS With Tables That Have Duplicate Field Names

MySQL DATE_FORMAT Issue

Using Hyphenated Table Names

Token Chooser
This is an incredibly important part of the Repeater module. When you click this link, the SQL query you enter into the Repeater SQL text area is run against the RackForms data source, or if you have supplied a valid connection via the individual Data Source boxes or though a DB Connector File, though the specified external data source.

RackForms then creates a list of default and dynamic variables for your query. The default list come from the functions RackForms provides for interactions such as Paging and Total Results displays. The dynamic variables come directly from your SELECT field list. For example, if you input the following into the Repeater SQL text area:

SELECT name, birth_date FROM person;

The Dynamic variable list will display field variables in the following format:

Variable name -> Function -> Update -> Flat Image -> DB Image -> Link -> PK -> Hidden -> Sort -> Sort Direction -> Search -> SQL type

For example, the sample SELECT call above would produce (shortened list):

name -> Function -> Update -> Flat Image -> DB Image -> Link -> PK -> Hidden -> Sort -> Sort Direction -> Search -> SQL type-> VAR_STRING
birth_date -> Function -> Update -> Flat Image -> DB Image -> Link -> PK -> Hidden -> Sort -> Sort Direction -> Search -> SQL type-> VAR_STRING -> VAR_STRING

All items except for SQL Type are links. Each link is a token that performs a different task when the form is built and run. When you click a link, it sends the token text to the Repeaters text area box, which can be in simple or WYSIWYG mode.

Thus, the process of building a dynamically generated page is to create an SQL statement; open the Token Chooser window to check your statement (by clicking the Token Chooser link); then create a layout in the text area box which you plug the tokens in to by clicking their links.

Learning which links do what is really the key to using the Repeater. The best way to learn is to watch the Basic Repeater Video in the Help Videos section.

Generate Template

This feature allows us to generate our Repeater Template automatically, for both display and multi-update forms. This process also adds a block of custom CSS to the pages 'Page JavaScript/CSS Code' block, which ensures the resulting template looks great under any display device.

We have two main options for this generator, creating a display-only form, and multi-update.

If we click the first option a few things happen: The first is RackForms runs the SQL Code in the Repeater SQL block, checking it for errors. If the code executes without issue we return a block of meta-data on the queries expected columns, and then create a Repeater template that displays all of these columns. Thus, it's key to note we can run any valid SQL in this block and RackForms will create the proper template.

If we click the second option: RackForms runs the SQL Code in the Repeater SQL block, checking it for errors. If the code executes without issue we return a block of meta-data on the queries expected columns, and then create a Repeater template that displays all of these columns in multi-update format. That is, each column's data is displayed as in input text field the user can edit submit.

We also enable multi-update mode in the form when we select this option, which means the query being run must include a Primary Key field in it's selected columns. If no Primary Key is found the process will fail and no template will be created.

Finally, both methods append a block of CSS to your page's Page JavaScript/CSS Code block. This style block contains an assortment of styles that target the Repeaters many elements, and can be edited at any time to suite your needs.

Please see this video for a brief demonstration of this feature.

DataTables

The job of RackForms is to automate tasks that would ordinarily take advanced knowledge or time to create. A perfect example of this is our DataTables implementation. DataTables is a powerful JavaScript library that converts basic table data into powerful, feature rich data tables.

It's key to note that by default, when we have RackForms create a basic repater page the output is indeed, basic HTML table data. We can then modify our Repater template to add greater functionality, such as paging, sorting, and filtering. While flexible, the downside to this approach is we do need to have some knowledge of programming topics, such as CSS, template creation, and HTML.

Using the DataTables feature eliminates these requirements by applying all of these features and more with a single menu selection.

RackForms currently ships with three DataTable modes:

• Basic - This mode applies the basic DataTables plugin to your Repeater template.
• Fixed Header + Responsive - This mode applies DataTables along with plugins to enable advanced functionality, including placing a Fixed header on the page top and making the table responsive.
• Responsive + Scroller - This mode applies DataTables along with plugins to enable advanced functionality, including making the table responsive and applying the "scroller" effect, which is simply a set height to your table content (600px), which users can then scroll through using standard scroll bars.

The table below lists the details of each feature:

• Fixed Header: When displaying tables with a particularly large amount of data shown on each page, it can be useful to have the table's header and / or footer fixed to the top or bottom of the scrolling window. This lets your users quickly determine what each column refers to rather than needing to scroll back to the top of the table. FixedHeader provides the ability to perform this action with DataTables tables. It operates by detaching the header and footer elements from the host table and attaching them to the top or bottom of the screen as required by the scrolling position of the window. This ensures that FixedColumns is fully compatible with DataTables and you can add complex interactions such as search elements in the table footer, just as you would with any other table.
• Responsive: In the modern world of responsive web design tables can often cause a particular problem for designers due to their row based layout. Responsive is an extension for DataTables that resolves that problem by optimizing the table's layout for different screen sizes through the dynamic insertion and removal of columns from the table.
• Scroller: Scroller is a virtual rendering plug-in for DataTables which allows large datasets to be drawn on screen very quickly. What the virtual rendering means is that only the visible portion of the table (and a bit to either side to make the scrolling smooth) is drawn, while the scrolling container gives the visual impression that the whole table is visible. This is done by making use of the pagination abilities of DataTables and moving the table around in the scrolling container DataTables adds to the page. The scrolling container is forced to the height it would be for the full table display using an extra element.
  RackForms Note: Please note RackForms supports the "DOM" only rendering mode for the scroller plugin, as in it doesn't use AJAX calls to fetch additional data, it simply applies scrolling behavior to a set table.

Important DataTables Implementation Note: By default the DataTables plugin requires certain class names be applied to various table elements to look correct. As RackForms strives to be plugin independent, we instead must apply the styles generated by one of the Repeater template generators to be present. Thus, when using the DataTables feature, please make sure to generate your template using one of the template generators first, then if needed, use the template tokens tool to customize.

Datatables And Paging / Sorting: Datatables overrides almost all of the RackForms settings for paging, sorting, and search. In fact, Datatables should be thought of as a replacement for these features. This means when creating a Repeater, one should always choose one or the other, not both.

Alternate Row Color

Checking this box ensures each builder row alternates colors. Please note this option has no effect for templates created with the Generate Template option, as those rows are always alternated.

Use Paging/Sorting

Initial Page Size

Please note that for technical reasons only the first run of a form will respect this value. That is, if we set this to 1, run the form and close it, then set it to 10 and then run the form again, the form will still only show 1 result.

This is normal behavior and is the result of the caching system Builder must use to present a proper end-user experience after the development process.

To get around this limitation simply add a Results Per Page token item to the form, as that way we can change the value as needed.

Sort Order

This is the default sorting order of your results.

Sort Criteria

Please note we can populate this field with a comma delimited list of columns to sort by. This is of course handy for forms where we need to sort by more than one column. Please note however, that if your form can be sorted (by adding the sort tokens), unless you specify the same multiple columns in your sort token, the initial sorting will be lost. Please see the sort token documentation below for more detailed information on making sure your tokens are set up properly.

It's also important that our column names do not have spaces. If they do, the Builder form may fail, or at minimum, the sorting logic will not work.

Relaxed Search

Conversely, you may want to create a form that starts off blank; the only rows returned to the user should be ones that have been specifically searched for. If that is the case, leave this box unchecked. When a user first loads the form, the search form will be empty. A classic example of this type of form would be an employee lookup form, where the user is required to input valid search data to return any results.

A few points of note: First, the term Relaxed Search is used to imply that the standard for returning information in this mode is not as tight as if this mode was enabled. This has consequences for multi-field search forms, in that the Join condition (see below under The Repeater Token Set > Dynamic Field Variables > Search > join) is ignored if only 1 field has an entered value. For example, a car search form might have Make, Model, and Year. The joins could be:

Relaxed Search means that even though our model field is joined with an AND, the user could search for Corvette and still return results. In many instances this is the preferred behavior, though not in all. If you want to make sure your logical joins are respected, you need to make sure this checkbox is unchecked.

Second, By default all rows will be returned unless you Enable Paging for the form. For small data sets returning all rows is fine, but larger ones it is not. If your form has more than 50 rows you should probably use paging. Please keep in mind if we enable paging we must also set a value for Sort Criteria. By default you should simply make this the primary key of the table being queried.

No Count(*) Rebuild

To help you understand why this option is important, it helps to know a little background. When you run a Repeater SQL query, RackForms, by default, will attempt to rewrite the query with a count(*) clause to retrieve the total row count*. This row count is used for several operations including paging and the #{*T_total_results} token. While this automatic rewrite allows you to create complex paging elements with almost no effort, the downside to this operation is the SQL query has to fit a pretty rigid mold. As already stated, no extra keywords are allowed in the SELECT statement, and so on.

*In fact, you can see exactly how RackForms is rewriting your queries by enabling the SQL Debug Mode (see below). Viewing this output shows you exactly how the *default* rewrite affects your SQL code.

The solution to this issue is the No Count(*) Rebuild checkbox. By checking this box you tell RackForms NOT to rewrite your query but instead run it untouched and retrieve the row count by issuing a count($result->fetchAll()) operation.

The potential downside to this method is if your result set is large you may run into PHP memory issues. However, this should not be an issue for the vast majority of users.

No Results Message

Alternate Rows

In terms of template implementation, alternating row colors are only applied to tr elements that have a class="alt" definition. That is, when we export the form RackForms looks for and applies PHP code to any block that has this option checked, as well as a class definition of alt.

By default all standard RackForms templates already have this class definition, so no extra work is needed. However, if we create our own templates, or we modify an existing template and accidentally erase this class attribute, alternating row colors will not be applied.

Alternate Color

Alternate Color 2

This is the secondary row color. Is blank (unset) by default, but can be defined as needed.

Paging Link

Paging Background

Paging Outline

Paging Non-Link

Paging Active

Allow User Updates Mode

However, if we wish to enable user update we have two modes:

Single Row Updates: This mode is based on the idea that we only want to update one row at a time. This is very useful for situations where we want maximum control over the update process. This is because in this mode we are responsible for setting the values of Repeater Update SQL and Repeater Update Variable List. Because of this we can thus mix and match which fields are available to be updated, as well as write the exact SQL code used to perform that task.

Multi-Row Updates: This mode is more convenient in many ways that Single Row Updates, as to use this mode we just supply the table name we wish to update via the Multi-Update Table Name property, and the Primary Key of the updating table via the Multi-Update Table Primary Key Name property.

This method of course differs from Single Row Updates, as here we process all rows on the page at once.

The downside to this convenience is we have little to no control over the update process. That said, for most uses this is a non-issue, as our update logic is almost always quite simple: "update this text field with this new value".

This is a general overview of the update modes, for a more complete picture please see the yellow call out directly below.

Allow File Uploads

We can collect meta information on the file upload and pass it to the SQL statement. We have three fields to choose from:

_mime - The MIME Type of the file.

_size - The size in Bytes of the file.

_name - The original name of the file.

To pass these values to your SQL statement add an underscore and the shortcut name to the file item name. For example, if we had a file upload item named image_data we would use this for the SQL Statement:

UPDATE fb_images SET image_data = ?, image_name = ? WHERE entry_id = ?

And this for the Parameters List:

image_data, image_data_name, id

Again, notice how we use image_data, then add an underscore plus the shortcut name, in this case, name, to the variable. This is almost identical to the process we use for the SQL+ Module.

One very important note on mixing and matching file/image uploads with non-file upload fields
RackForms was designed to only update a file field if a user has actually selected a file to load for that record. This means so long as the user doesn't select a new file to upload, the file row will never be touched upon submission. This is so because technically speaking, RackForms automatically terminates any file update SQL statement that would place null data into the existing file slot. In short, we are not allowed to upload 'nothing' into an existing slot.

This is fine for forms that only have file data, but most of our forms will mix and match file and non-file data.

To address these types of forms, we must break the Repeater Update SQL statement into two logical components: one SQL statement for each file update, and one SQL statement for everything else.

How do we do this? Simple: replace logical components with multiple SQL statements, then take advantage of RackForms' ability to handle multiple SQL statements in one block.

So for example, if we had a builder form that had image and text update in one block, we would rewrite this single SQL UPDATE statement:

UPDATE fb_images SET image_caption = ?, image_description = ?, image_data = ? WHERE image_id = ?;

as this:

UPDATE fb_images SET image_caption = ?, image_description = ? WHERE image_id = ?;

UPDATE fb_images SET image_data = ? WHERE image_id = ?

Likewise, we would also make sure to update the Repeater Update Variable List from this:

image_caption, image_description, image_data, image_id;

To instead be:

image_caption, image_description, image_id;

image_data, image_id

It should be noted that from an architectural standpoint it is highly recommended that your file data table only hold the base file data and the name, mime, and size properties. Any other meta information such as upload date, file meta data (such as description, caption, etc) and security settings should be placed into a separate table joined by a foreign key. Doing so will ensure that your database has the maximum portability and redundancy. A good example of this is the fb_demo and fb_images tables.

Prevent Null Updates

If either of these conditions is met that row's update is skipped. However, this does not mean any other items are skipped, even those on the same row as the skipped update. For example, if we have two columns being updated, name and age; if the name update fails but the user selected a valid age, the age update will still be processed.

Repeater Update SQL

The format is standard UPDATE syntax, as in:

UPDATE fb_demo SET name = ?, email = ? WHERE id = ?

RackForms will take any fields supplied in the template, match them with the repeater update variables, and post the change to your database.

Of course most importantly we need to supply a proper set of variables including the value(s) passed to the WHERE clause!

Multiple SQL Statements In One Box
We can include multiple SQL statements in one block. The syntax for this is the same as what you would type for normal SQL, only you must separate each SQL statement with a semicolon. Please note you must also separate the variables with a semicolon that matches the corresponding SQL. For example, this SQL:

UPDATE cars SET year = ?, make = ? WHERE id = ?; UPDATE fb_images SET image_data = ? WHERE entry_id = ?

Would work with this variable list:

year, make, id; db_image, id

Notice how year, make, id; match the first SQL statement of:

UPDATE cars SET year = ?, make = ? WHERE id = ?;

And how the same is true of the second statement.

Where Multiple Statement are Required

Repeater Update Variable List

It must be noted that you can also include PHP variables in this area, the format is:

variable_name

That is, unlike most other RackForms fields, you do not need to add a dollar sign or any token characters such as the braces or pound sign.

A common way to do this then is to create a variable such as a DATETIME in the PHP Top Code section:

<?php
session_start();
// Your Code Below...
$datetime = date('Y-m-d H:i:s', time());
?>

Then include the variable in the Variable list as just: datetime

Multi-Update Table Name

Please note that if using PDO or MySQLi RackForms will automatically set this value and Multi-Update Table Primary Key Name for us based on our Repeater SQL statement and a query of the database for the Primary Key. It only performs this for us however, if these fields are blank.

Multi-Update Table Primary Key Name

For example, to update the fb_demo table we would use fb_demo and id as the Multi-Update Table Name and Multi-Update Table Primary Key Name fields, respectively.

Key to this process is the column name we specify should ALWAYS be a real, AUTOINCREMENT, NOT NULLPrimary Key. RackForms does not check this at form creation time however, which means if we do not use such a field we risk running into a situation where the field is empty or null (has no value), at which point RackForms will simply issue a PHP die() statement killing the current repeater rendering process.

If this happens and we have debug mode enabled you will get a message in the form saying this has happened, if we do not have debug mode on the form will simply stop being rendered.

Update This TIMESTAMP Column

This option allows us to have RackForms perform an update on this rows TIMESTAMP field, if present, after an update operation.

The main use for this type of logic will be when we have a table that needs to have the most recent operation's time of action saved. We could create a database trigger ON UPDATE to complete this step, but having the option in RackForms is generally much easier.

Please note by default this field is blank, which means no update operation will take place. However, if we place a value this field must exists in the same table as the update operation, and must be of type TIMESTAMP.

Auto-Redirect After Update?

Please note that if our form has User Delete Mode set to Multi-Row Delete this setting is ignored. This is simply because if we want to process any delete item logic we cannot skip out (via the redirect) of the page until the delete logic has completed.

In practice this effect is going to mean very little to us as form builders, and is only mentioned here for the sake of completeness.

PHP Code To Run After Update

Using this area let's us create all sorts of cool logic. For example, let's say we wanted to redirect to a new page after the update, but we also wanted to use the id of the last updated item to create a query string. To do so we would create a PHP header() call like so:

header("Location: http://www.rackforms.com/index.php?id={$_POST['id']}");
exit;

The most important part of this example is that so long as we include the proper name of the POST field our UPDATE form contains, we can use the live value in our header() call.

User Delete Mode

Get to know the two delete modes in RackForms with this introduction video!

Deleting records from a database is a very common task. However, it's also one that carries with it a great deal of responsibility from the users we entrust with this task.

Select the type of user deletes we want the form to support.

Single Row Delete is a mode where we write the SQL and define the parameters to support the DELETE action. This is the preferred mode for power users, as it gives us total control over the DELETE process.

The one big drawback to this mode however is we can only DELETE one row at a time.

Multi-Row Delete is made for quickly adding the ability to delete multiple rows in one shot. The downside is unlike Single Row Update mode we cannot define the SQL that's run against the database. Instead, we define two fields to tell RackForms the table to work with (via Multi-Delete Table Name), and the primary key (via Multi-Delete Table Primary Key Name). RackForms takes these two pieces of information and creates all the back end code to handle the DELETE operation.

While it's true we do not have direct control over the SQL being written in multi-delete mode, the system is robust enough to handle most DELETE operations. When you combine the fact then that this mode requires no SQL and handles multiple row deletes, this is the mode you'll usually want to choose -- it's easy and powerful.

User Interface Note: Just like User Updates Mode we can select from single or multi-delete mode at will. If we select Single Row Delete the interface will only show those elements that are used for that mode. If we choose Multi-Row Delete the interface will show the Multi-Delete Table Name and Multi-Delete Table Primary Key Name fields, which are described below.

Implementing Multi-Row Delete forms is quite simple:

1. Start by selecting a template with Multi-Delete in the name.

2. Change the Repeater SQL block to match your table and then use the token chooser to set the proper fields.

A Multi-Delete template is similar to most other templates, the two big differences are the use of the *F_multi_delete_checkbox|| and *M_multi_update_button|,Update/Delete Record(s),Multi-Delete Confirmation Message| tokens.

These two tokens work together by placing checkboxes on the form so the user can select which rows they want to delete, and a submit button so that when we're ready to remove our rows the user can do so.

Confirm Record Delete?

The only exception to this rule is when we allow multi-deletes. In these cases because we're already providing such massive power to the user it may simply be because we, the form designers, are the only ones who will ever use the form anyway (or some other high-trust user).

In these cases it may be easier to disable any prompt in the first place.

Please also be aware that when using a form that has multi-updates and multi-deletes, if we have this setting enabled even if we do not delete a record we will still get a prompt asking if we're sure we wish to continue.

In other words this setting, when used with a multi-update forms, creates a prompt even though multi-update forms do not support prompts. This can be handy for added security, though again, by their very nature multi-updates are hugely destructive if in the wrong hands, so care should be taken at all times regardless!

Repeater Delete SQL

DELETE FROM fb_demo WHERE id = ?

Of course of paramount concern is the WHERE clause.

Multiple SQL Statements In One Box
We can include multiple SQL statements in one block. The syntax for this is the same as what you would type for normal SQL, only you must separate each SQL statement with a semicolon. Please note you must also separate the variables with a semicolon that matches the corresponding SQL. For example, this SQL:

DELETE FROM cars WHERE id = ?; DELETE FROM fb_images WHERE entry_id = ?

Would work with this variable list:

id; id

As a general rule though, although you can use multiple SQL statements in RackForms for DELETE queries, it may be worth looking into Foreign Keys for handling cascading deletes to implement a more robust solution.

Repeater Delete Variable List

This is the list of variables which will be used to determine which rows are removed. Again, chief among these variables is the value passed to the WHERE clause, which needs to be a proper PK field.

By proper we mean when we remove a record from a database we need to be very careful how this is done. The best and most common way to handle this is to use a Primary Key (PK) on the table in question, then use this unique PK value to tell the WHERE clause exactly which rows gets removed.

We can include PHP variables in this area, the format is:

$variable_name

A common way to do this then is to create a variable such as a DATETIME in the PHP Top Code section:

<?php
session_start();
// Your Code Below...
$datetime = date('Y-m-d H:i:s', time());
?>

Then include the variable in the Variable list as just: $datetime

As noted above, in Build 641 we can now use multiple SQL statement in one box. If we do so, we must be sure to separate each statements parameters with a semicolon.

Multi-Delete Table Name

Multi-Delete Table Primary Key Name

PHP Code To Run After Delete

SQL Debug Mode

If running multi-update or multi-delete queries, this option shows a good bit of information on the query that was run against the database server.

The Repeater Token Set

The RackForms Builder Repeater works by transforming tokens into code when you run your form. Tokens allow you to create complex form logic with the minimum amount of coding, all while providing a powerful interface for creating more complex logic should you need it.

Tokens come in many forms, from field items to search buttons. Token are divided into two main categories, Built-In Variables and Dynamic Field Variables. Built-In Variables are those tokens which are constant across all forms you build. Dynamic Field Variables are custom created for each SQL query you place into the Repeater SQL box.

In this list we shall list out the tokens available to you, and how to use each.

IMPORTANT NOTE: Prior to Build 640 each token must be separated by a space.

<?php
    function upper($v){
    return strtoupper($v);
}
?>

<?php
function format_price($num){
	return '$' . number_format($num, 0, '.', ',');	
}
?>
            

session_start();

function func_openings($ct,$job_id){
  if($ct !== 0 && is_numeric($ct)){
    echo "<a href=\"add_volunteer.php?job_id={$job_id}\">Sign Up</a>";
  }
}