Once you get connection object you are ready to decide what data should take part in load/update operations. Where all necessary data is placed in one database table you should use the render_table method:

    grid.render_table "grid50","item_id","item_nm,item_cd", "", ""

The parameters of this method are:

• database table name
• name of identity field ¹⁾
• list of fields which should be used as values of component item (cells of grid, item label in tree, text of option in combo)

This is all you need to make connector implement select, insert, update and delete operations.

You are allowed to use any SQL statements to populate any dhtmlx component through dhtmlxConnector. This is possible with the render_sql method:

        grid.render_sql "SELECT * from tableA INNER JOIN tableB  ON tableA.id=tableB.id", "table_a_id","name,price", "", ""

The parameters of the render_sql method are the following:

• sql statement
• field to use as identifier ²⁾
• list of fields which should be used as values of component item (cells for grid, item label for tree, text of option for combo)
• parent ID field name for hierarchical structures (required for tree and treegrid) *

In case your SQL query was against single table, it is quite probable that insert/update/delete operations do not require any additional code. dhtmlxConnector will parse your SQL and generate insert/update/delete statements based on used table and fields names.

If your SQL statement contains more than one table, connector will not be able to generate insert/update/delete operations correctly, so you will need do one from next

• define sql for each operation manually
• use server side events to define your own processing logic
• define different configs for select and update operations

The 3rd approach shown in below sample

    if grid.is_select_mode() then ' code for loading data
        grid.render_sql "Select * from tableA, tableB  where  tableA.id=tableB.id", "a.id","name,price,other", "", ""
    else ' //code for other operations - i.e. update/insert/delete
        grid.render_table "tableA","id","name,price", "", ""
    end if

With such init code grid will be loaded with three columns of data from 2 tables, but during saving only data from first table will be saved.

Last parameter of render_sql and render_table allows to define list of fields which will be used for rendering in grid and in update|insert operations, but command can be extended to define additional fields, which will be extracted from DB and can be mapped to different properties of records ( userdata, row styles, images, etc. ).

grid.render_table "tableA","id","name,price","extra1,extra2", ""
' or
grid.render_sql "Select * from tableA, tableB  where  tableA.id=tableB.id", "table_a_id","name,price,other","extra1,extra2", ""

extra1 and extra2 fields will be available in all server side event of grid, but will not be sent to server side, and will not be included in update|insert operations.

In case of Tree and TreeGrid , both render_sql and render_table accept one more parameter - relation ID. For default treegrid hierarchy - this is name of field , which will be used to link parent and child records.

treeGridConn.render_table "tableA","id","name,price","","parent_id"
' or
treeGridConn.render_sql "Select * from tableA, tableB  where  tableA.id=tableB.id", "a.id","name,price,other","","parent_id"

You can use aliases for DB field names to made later usage of extracted data more usable ( will have sense only if your are using server side events )

grid.render_table "tableA","id","name,price(product_price)", "", ""
' or
grid.render_sql "Select *,tableA.id as aid from tableA, tableB  where  tableA.id=tableB.id", "tableA.id(aid)","name,price(product_price),other", "", ""