1 Execution types
There are three different types of execution of SQL Statements:
- XSQL-Script program
- Prepared queries
- Non prepared queries
If the SQL Statement is a XSQL-Script
program, the execution is done via the XSQL-Scrpit
engine.
If it is a SQL, then the statement can be prepared or not prepared.
Some circumstances produce that the query cannot be prepared.
- When the query parameter is used in a built-in function (matches, nvl, etc), as for example
Copy
<select> <columns>col1, col2</columns> <from table='tab1' /> <where><nvl>col3, ?<nvl> = 'A'</where> </select>
- When the query parameter is between quotes, as for example
Copy
<select> <columns>col1, col2</columns> <from table='tab1' /> <where>col3 LIKE '%?'</where> </select>
In these cases the statement is parsed, replacing the query parameters with the values.
The following example shows the replacement of values:
SELECT col1, col2 FROM tab1 WHERE col3 LIKE '%val1'
2 Using prepared statements
Sometimes it is more convenient to use a PreparedStatement object for sending SQL statements to the database. This special type of statement is derived from the more general class, Statement, that you already know.
If you want to execute a Statement object many times, it usually reduces execution time to use a PreparedStatement object instead. The main feature of a PreparedStatement object is that, unlike a Statement object, it is given a SQL statement when it is created. The advantage to this is that in most cases, this SQL statement is sent to the DBMS right away, where it is compiled. As a result, the PreparedStatement object contains not just a SQL statement, but a SQL statement that has been precompiled. This means that when the PreparedStatement is executed, the DBMS can just run the PreparedStatement SQL statement without having to compile it first.
Although PreparedStatement objects can be used for SQL statements with no parameters, you probably use them most often for SQL statements that take parameters. The advantage of using SQL statements that take parameters is that you can use the same statement and supply it with different values each time you execute it.
Examples of this can be found in the following sections.
String queryStatement = "SELECT col1, col2 " + " FROM tab1 " + " WHERE col3 = ?"; PreparedStatement ps = con.prepareStatement(queryStatement); // Supplying Values for PreparedStatement Parameters ps.setString(1, "val1"); ResultSet rs = ps.executeQuery();
3 Flow of execution
Process before execute the statement at the database
4 References to record fields
The references to values of the record fields are defined via
${field_name}
This represents a change respect the previous versions where was possible to reference values using '#' symbol. For the converted tables the use of '#' it is not longer available.
5 SQL Statements at the application form fields
There are some tables where the programmer can store SQL statements. The tables are showed in this board.
The converted flag indicates that the table uses the new implementation.
Table name | Column name | Converted |
---|---|---|
wic_jrep_object | rep_stmt |
|
wic_jrep_box_calendar | cal_sqlstmt |
|
wic_jrep_box_sql_d3graph | sql_stmt |
|
wic_jrep_box_sqldot | sqlstmt |
|
wic_jrep_box_sqlgmap | gmap_center_stmt |
|
wic_jrep_box_sqlgmap_edit | gmap_edit_sqlstmt |
|
wic_jrep_box_sqlgmap_layers | layer_stmt |
|
wic_jrep_box_sqlgmap_layers | layer_track_stmt |
|
wic_jrep_box_sqlimglist | sqli_sqlstmt |
|
wic_jrep_box_sqljcharth | jchart_sqlstmt |
|
wic_jrep_box_sqljsobj | sqlstmt |
|
wic_jrep_box_sqlobj | sqlo_sqlstmt |
|
wic_jrep_box_sqlobj | sqlo_sqlstmt |
|
wic_jrep_box_sqltable | sqlt_sqlstmt |
|
wic_jrep_form_query | query_stmt |
|
wic_jrep_form_butt | butt_foreach |
|
wic_jrep_form_butt | butt_message |
|
wic_jrep_form_butt | butt_stmt |
|
wic_jrep_form_import_sqlitem | sqli_stmt |
|
wic_jrep_form_tabs | tab_exists_data |
|
wic_jrep_form_tabs | form_print_stmt_before |
|
wic_jrep_form_tabs | form_print_stmt_after |
|
wic_jdic_softref_help | sref_query |
|