SELECT parent.parent_key, parent.data_1, child.child_key, child.parent_key FROM child LEFT OUTER JOIN parent ON parent.parent_key = child.parent_key ORDER BY parent.parent_key, child.child_key; Tip: Outer joins are confusing at the best of times, so don’t make the situation worse by using both LEFT OUTER JOIN and RIGHT OUTER JOIN operators. Stick with LEFT OUTER JOIN and your code will be easier to understand because the preserved table will always be on the same side. 3.4.5 FULL OUTER JOIN The FULL OUTER JOIN operator is an extension that combines both LEFT OUTER JOIN and RIGHT OUTER JOIN functionality. In other words, all the rows in both tables are preserved, and both tables are null-supplying when they have to be. Here’s how it works: First, the INNER JOIN is computed using the ON condition. Second, any rows from the left-hand table that weren’t included by the INNER JOIN process are now appended to the result set, with NULL values used for the columns that would normally come from the right-hand table. And finally, any rows from the right-hand table that weren’t included by the INNER JOIN process are now appended to the result set, with NULL values used for the columns that would normally come from the left-hand table. Here’s what the FULL OUTER JOIN looks like, using the parent and child tables: SELECT parent.parent_key, parent.data_1, child.child_key, child.parent_key FROM parent FULL OUTER JOIN child ON parent.parent_key = child.parent_key ORDER BY parent.parent_key, child.child_key; Now the result set contains all the columns from all the rows in both tables. It includes parent-and-child combinations from the INNER JOIN, plus the orphan child row from the RIGHT OUTER JOIN, plus the childless parent rows from the LEFT OUTER JOIN. parent. parent. child. child. parent_key data_1 child_key parent_key ========== ======= ========= ========== NULL NULL 7 NULL orphan 1 x 4 1 parent and child 1 x 5 1 parent and child 1 x 6 1 parent and child 2 x NULL NULL parent with no children 3 y NULL NULL parent with no children It’s important to understand that the ON condition only applies to the first step in any OUTER JOIN process. All the rows in the preserved table(s) are included in the final result set no matter what the ON condition says. Here’s an example where the restriction parent.data_1 = 'x' has been added to the ON condition of the LEFT OUTER JOIN presented earlier: 86 Chapter 3: Selecting Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. SELECT parent.parent_key, parent.data_1, child.child_key, child.parent_key FROM parent LEFT OUTER JOIN child ON parent.parent_key = child.parent_key AND parent.data_1 = 'x' ORDER BY parent.parent_key, child.child_key; In this case the result set is exactly the same as it was before: parent. parent. child. child. parent_key data_1 child_key parent_key ========== ======= ========= ========== 1 x 4 1 parent and child 1 x 5 1 parent and child 1 x 6 1 parent and child 2 x NULL NULL parent with no children 3 y NULL NULL parent with no children The fact that a row with parent.data_1 = 'y' is included even though the ON con - dition specified only rows with 'x' were to be included often comes as a surprise. It’s the way an OUTER JOIN works, and it’s the way it’s supposed to work, but it is often not exactly what you want. Tip: Be very careful what you code in the ON condition of an OUTER JOIN. A good rule of thumb is to only code conditions that affect how rows from both tables are joined, not conditions affecting only one or the other table. If you want to eliminate rows in one or the other table before the OUTER JOIN is applied, use a derived table or a view. 3.5 Derived Tables A derived table is a mechanism where you can code an entire subquery inside a FROM clause, and have the result set from that subquery treated like any other table term in the FROM clause. <derived_table> ::= <subquery> [ AS ] <correlation_name> [ <derived_column_name_list> ] <derived_column_name_list> ::= "(" <alias_name_list> ")" <alias_name_list> ::= <alias_name> { "," <alias_name> } <alias_name> ::= <identifier> In the previous example, a LEFT OUTER JOIN was written using an ON condi - tion that didn’t satisfy the requirements, (only parent rows with parent.data_1 = 'x' were to be included in the result set). The problem was that a row with par - ent.data_1 = 'y' was included because of the way OUTER JOIN operators work. Here’s how a derived table can be used to solve that problem by eliminating the unwanted rows before the LEFT OUTER JOIN is applied: SELECT parent.parent_key, parent.data_1, child.child_key, child.parent_key FROM ( SELECT * FROM parent WHERE parent.data_1 = 'x' ) AS parent Chapter 3: Selecting 87 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. LEFT OUTER JOIN child ON parent.parent_key = child.parent_key ORDER BY parent.parent_key, child.child_key; Tip: The minimum coding requirements for a derived table are a subquery inside brackets, followed by a correlation name by which the subquery’s result set will be known in the rest of the FROM clause. If all you want from a derived table is to apply a WHERE clause to a table, there’s no reason not to use SELECT * in the subquery. You can also use the table name as the correlation name if you want, and you don’t have to specify alias names for any of the columns; in other words, the derived table can look exactly like the original table, as far as the table and column names are concerned. Also, you don’t necessarily have to worry about performance; the query optimizer does a pretty good job of turning subqueries into joins and eliminating columns that aren’t actually needed. In the LEFT OUTER JOIN example above, the derived table is called “parent” and it looks like this: ( SELECT * FROM parent WHERE parent.data_1 = 'x' ) AS parent Now only rows with parent.data_1 = 'x' are considered for the LEFT OUTER JOIN with the child table, and the final result set looks like this: parent. parent. child. child. parent_key data_1 child_key parent_key ========== ======= ========= ========== 1 x 4 1 parent and child 1 x 5 1 parent and child 1 x 6 1 parent and child 2 x NULL NULL parent with no children It is sometimes tempting to use a WHERE clause in the outer SELECT, instead of an ON condition inside a FROM clause, especially if the ON condition doesn’t work and you don’t want to bother with a derived table. With an OUTER JOIN, however, a WHERE clause is like an ON condition — some - times it does what you want, and sometimes it doesn’t. In particular, a WHERE clause is applied long after the FROM clause is completely evaluated, and it can accidentally eliminate rows where columns were filled with NULL values from the null-supplying table. Here is an example using the FULL OUTER JOIN from earlier; an attempt is being made to restrict the parent rows to ones where parent.data_1 = 'x' by adding that restriction in a WHERE clause: SELECT parent.parent_key, parent.data_1, child.child_key, child.parent_key FROM parent FULL OUTER JOIN child ON parent.parent_key = child.parent_key WHERE parent.data_1 = 'x' ORDER BY parent.parent_key, child.child_key; According to the explanation in Section 3.2, “Logical Execution of a SELECT,” the FROM clause is evaluated first and the WHERE clause is applied later. That means the initial result of the FROM clause looks exactly as it did earlier, in 88 Chapter 3: Selecting Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Section 3.4.5, “FULL OUTER JOIN,” because the WHERE clause hasn’t been applied yet: parent. parent. child. child. parent_key data_1 child_key parent_key ========== ======= ========= ========== NULL NULL 7 NULL this row is going to disappear: not OK 1x41 1x51 1x61 2 x NULL NULL 3 y NULL NULL this row is going to disappear: OK When the WHERE clause is applied to produce the final result set, two rows are eliminated, not just one. The first row above is eliminated because parent.data_1 is NULL and the last row is eliminated because parent.data_1 is 'y'; neither match the WHERE condition parent.data_1 = 'x'. In other words, the FULL OUTER JOIN isn’t a FULL OUTER JOIN any - more because the orphan child row is no longer represented in the final result set; adding the WHERE clause effectively turned it into a LEFT OUTER JOIN. parent. parent. child. child. parent_key data_1 child_key parent_key ========== ======= ========= ========== 1x41 1x51 1x61 2 x NULL NULL In fact, if there were a thousand orphan rows in the child table, they would all be eliminated by that WHERE clause, when all we wanted to do is eliminate one parent row, the one with parent.data_1 different from 'x'. The solution once again is a derived table that eliminates the unwanted par- ent row before the FULL OUTER JOIN is computed: SELECT parent.parent_key, parent.data_1, child.child_key, child.parent_key FROM ( SELECT * FROM parent WHERE parent.data_1 = 'x' ) AS parent FULL OUTER JOIN child ON parent.parent_key = child.parent_key ORDER BY parent.parent_key, child.child_key; Now the result set makes more sense — the orphan child row is included, and the unwanted parent row is eliminated: parent. parent. child. child. parent_key data_1 child_key parent_key ========== ======= ========= ========== NULL NULL 7 NULL orphan 1 x 4 1 parent and child 1 x 5 1 parent and child 1 x 6 1 parent and child 2 x NULL NULL parent with no children Chapter 3: Selecting 89 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Note: It is very common for a WHERE clause to accidentally eliminate rows in an OUTER JOIN. Typically, a LEFT OUTER JOIN or RIGHT OUTER JOIN becomes an INNER JOIN, or a FULL OUTER JOIN becomes a LEFT or RIGHT OUTER JOIN. Here’s the technical explanation for this symptom: Any null-intolerant predicate that refers to attributes from a null-supplying table will eliminate NULL-supplied rows from the result. A null-intolerant predicate is a predicate that cannot evaluate to true if any of its inputs are NULL. Most SQL predicates, such as comparisons, LIKE, or IN predicates, are null-intolerant. Examples of null-tolerant predicates are IS NULL and any predicate p qualified by a null-tolerant truth value test, such as p IS NOT TRUE. (from “Semantics and Compatibility of Transact-SQL Outer Joins” by G. N. Paulley, 15 February 2002, iAnywhere Solutions Technical White Paper, Document Number 1017447.) 3.6 Multi-Table Joins The syntax of the FROM clause allows for joins among endless numbers of tables, with or without parentheses to create nested table expressions, and with or without ON conditions on each join. In most cases, parentheses are not required, but it is a very good idea to provide an ON condition for every join operator whenever possible. <table_expression> ::= <table_term> | <table_expression> CROSS JOIN <table_term> | <table_expression> [ <on_condition_shorthand> ] do not use <join_operator> <table_term> [ <on_condition> ] use this instead <table_term> ::= <table_reference> | <view_reference> | <derived_table> | <procedure_reference> | "(" <table_expression_list> ")" | <lateral_derived_table> <on_condition_shorthand> ::= KEY foreign key columns; do not use | NATURAL like-named columns; do not use <join_operator> ::= <inner_join> | <left_outer_join> | <right_outer_join> | <full_outer_join> In the absence of parentheses, join operators are evaluated from left to right. That means the first pair of table terms are joined to create a virtual table, then that virtual table is joined to the third table term to produce another virtual table, and so on. The following example shows a four-way join among tables that exist in the ASADEMO database that ships with SQL Anywhere Studio 9. Here is the schema for the four tables (customer, product, sales_order, and sales_order_items) plus two other tables that will appear in later examples (employee and fin_code): CREATE TABLE customer ( id INTEGER NOT NULL DEFAULT AUTOINCREMENT, fname CHAR ( 15 ) NOT NULL, lname CHAR ( 20 ) NOT NULL, 90 Chapter 3: Selecting Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. address CHAR ( 35 ) NOT NULL, city CHAR ( 20 ) NOT NULL, state CHAR ( 16 ) NULL, zip CHAR ( 10 ) NULL, phone CHAR ( 12 ) NOT NULL, company_name CHAR ( 35 ) NULL, PRIMARY KEY ( id ) ); CREATE TABLE employee ( emp_id INTEGER NOT NULL PRIMARY KEY, manager_id INTEGER NULL, emp_fname CHAR ( 20 ) NOT NULL, emp_lname CHAR ( 20 ) NOT NULL, dept_id INTEGER NOT NULL, street CHAR ( 40 ) NOT NULL, city CHAR ( 20 ) NOT NULL, state CHAR ( 16 ) NULL, zip_code CHAR ( 10 ) NULL, phone CHAR ( 10 ) NULL, status CHAR(2)NULL, ss_number CHAR ( 11 ) NULL, salary NUMERIC ( 20, 3 ) NOT NULL, start_date DATE NOT NULL, termination_date DATE NULL, birth_date DATE NULL, bene_health_ins CHAR(2)NULL, bene_life_ins CHAR(2)NULL, bene_day_care CHAR(2)NULL, sex CHAR(2)NULL ); CREATE TABLE fin_code ( code CHAR(2)NOTNULL PRIMARY KEY, type CHAR ( 10 ) NOT NULL, description CHAR ( 50 ) NULL ); CREATE TABLE product ( id INTEGER NOT NULL, name CHAR ( 15 ) NOT NULL, description CHAR ( 30 ) NOT NULL, size CHAR ( 18 ) NOT NULL, color CHAR(6)NOTNULL, quantity INTEGER NOT NULL, unit_price NUMERIC ( 15, 2 ) NOT NULL, PRIMARY KEY ( id ) ); CREATE TABLE sales_order ( id INTEGER NOT NULL DEFAULT AUTOINCREMENT, cust_id INTEGER NOT NULL REFERENCES customer ( id ), order_date DATE NOT NULL, fin_code_id CHAR(2)NULL REFERENCES fin_code ( code ), region CHAR(7)NULL, sales_rep INTEGER NOT NULL REFERENCES employee ( emp_id ), PRIMARY KEY ( id ) ); CREATE TABLE sales_order_items ( id INTEGER NOT NULL REFERENCES sales_order ( id ), line_id SMALLINT NOT NULL, prod_id INTEGER NOT NULL REFERENCES product ( id ), quantity INTEGER NOT NULL, ship_date DATE NOT NULL, PRIMARY KEY ( id, line_id ) ); Chapter 3: Selecting 91 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. The customer table holds information about companies that may buy products, the product table defines each product for sale, sales_order records each sale to a customer, and the sales_order_items table is a many-to-many relationship between product and sales_order to record which products were included in which orders. There are foreign key relationships among these tables to define the relationships, and these foreign key relationships are used in the ON condi - tions of the four INNER JOIN operations, which gather all the information about which products were sold to which customers as part of which order: SELECT customer.company_name, sales_order.order_date, product.name, product.description, sales_order_items.quantity, product.unit_price * sales_order_items.quantity AS amount FROM customer INNER JOIN sales_order ON sales_order.cust_id = customer.id INNER JOIN sales_order_items ON sales_order_items.id = sales_order.id INNER JOIN product ON product.id = sales_order_items.prod_id ORDER BY customer.company_name, sales_order.order_date, product.name; Here’s how this FROM clause works from a logical point of view: n First, rows in customer are joined with rows in sales_order where the cus- tomer id columns match. The virtual table resulting from the first INNER JOIN contains all the columns from the customer and sales_order tables. n In the second INNER JOIN, the rows from the first virtual table are joined with rows in sales_order_item where the sales order id columns match. Note that the columns in the first virtual table may be referred to using their base table name; e.g., sales_order.order_id in the second ON condition. The result of the second INNER JOIN is a new virtual table consisting of all the columns in customer, sales_order, and sales_order_item. n In the final INNER JOIN, the rows from the second virtual table are joined with rows in product where product id columns match. The result of the final INNER JOIN is a virtual table consisting of columns in all four tables. Even though this is (conceptually speaking) a single virtual table, individ - ual columns may still be referred to using their original table names; e.g., customer.company_name in the ORDER BY clause. The final result set consists of 1,097 rows. Here are the first six rows, showing the detail of the first three orders placed by Able Inc.: company_name order_date name description quantity amount ============ ========== ============ ================= ======== ====== Able Inc. 2000-01-16 Sweatshirt Hooded Sweatshirt 36 864.00 Able Inc. 2000-01-16 Sweatshirt Zipped Sweatshirt 36 864.00 Able Inc. 2000-03-20 Baseball Cap Wool cap 24 240.00 Able Inc. 2000-04-08 Baseball Cap Cotton Cap 24 216.00 Able Inc. 2000-04-08 Baseball Cap Wool cap 24 240.00 Able Inc. 2000-04-08 Visor Cloth Visor 24 168.00 Each ON condition applies to the preceding join operator. The following FROM clause uses parentheses to explicitly show which ON goes with which INNER 92 Chapter 3: Selecting Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. JOIN in the preceding example; note that this particular FROM clause performs exactly the same function with or without the parentheses: FROM(((customer INNER JOIN sales_order ON sales_order.cust_id = customer.id ) INNER JOIN sales_order_items ON sales_order_items.id = sales_order.id ) INNER JOIN product ON product.id = sales_order_items.prod_id ) Parentheses are useful in arithmetic expressions when you have to override the natural order of execution of the different operators (e.g., if you want addition to come before multiplication). Even if they’re not required, parentheses in arith - metic expressions help the reader understand the order of evaluation. Those arguments do not apply as strongly to parentheses in the FROM clause. First of all, there is no difference in precedence among the different join operators like INNER JOIN and LEFT OUTER JOIN; without parentheses they’re simply evaluated from left to right. Also, FROM clauses tend to be long, drawn-out affairs where matching parentheses appear far apart, so they’re not much help to the reader. Even in the simple example above, it’s hard to see what the parenthe- ses are doing; an argument can be made that the version without parentheses is easier to read. Having said that, parentheses in the FROM clause are sometimes necessary and helpful. The following example illustrates that point using the four tables in the ASADEMO database discussed above: customer, product, sales_order, and sales_order_items. The requirement is to show how many of each kind of shirt were sold to each customer in Washington, D.C., including combinations of product and customer that had no sales. In other words, show all the combina- tions of Washington customers and shirt products, whether or not any actual sales were made. At first glance it appears four joins are required: a CROSS JOIN between customer and product to generate all possible combinations, a LEFT OUTER JOIN between customer and sales_order to include customers whether or not they bought anything, a LEFT OUTER JOIN between product and sales_order_items to include products whether or not any were sold, and an INNER JOIN between sales_order and sales_order_items to match up the orders with their order items. Perhaps it is possible to write these four joins, in the right order, with or without parentheses, but a simpler solution uses a divide-and-conquer approach: n First, separately and independently compute two different virtual tables: the CROSS JOIN between customer and product, and the INNER JOIN between sales_order and sales_order_items. n Second, perform a LEFT OUTER JOIN between the first and second vir - tual tables. Parentheses are used to separate the first step from the second. Here is the pseudocode for the FROM clause using this approach: SELECT FROM ( all the combinations of customer and product ) LEFT OUTER JOIN ( all the matching combinations of sales_order and sales_order_items ) WHERE Chapter 3: Selecting 93 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. The full SELECT is shown below; the FROM clause has only three joins, two of them nested inside parentheses to create two simple virtual tables. The final LEFT OUTER JOIN combines these two virtual tables using an ON clause that refers to all four base tables inside the two virtual tables. The parentheses make it easy to understand: The CROSS JOIN is the simplest kind of join there is, and the INNER join is a simple combination of sales_order rows with their associ - ated sales_order_items row. SELECT customer.company_name AS company_name, product.name AS product_name, product.description AS product_description, SUM ( sales_order_items.quantity ) AS quantity, SUM ( product.unit_price * sales_order_items.quantity ) AS amount FROM ( customer CROSS JOIN product ) LEFT OUTER JOIN ( sales_order INNER JOIN sales_order_items ON sales_order_items.id = sales_order.id ) ON customer.id = sales_order.cust_id AND product.id = sales_order_items.prod_id WHERE customer.state = 'DC' AND product.name LIKE '%shirt%' GROUP BY customer.company_name, product.name, product.description ORDER BY customer.company_name, product.name, product.description; The final result is shown below. There are two customers in Washington, D.C., and five different kinds of shirts for sale, making for 10 combinations of cus- tomer and product. Five combinations had no sales as shown by the NULL values in quantity and amount, and five combinations did have actual sales. company_name product_name product_description quantity amount ======================= ============ =================== ======== ======= Hometown Tee's Sweatshirt Hooded Sweatshirt 24 576.00 Hometown Tee's Sweatshirt Zipped Sweatshirt NULL NULL Hometown Tee's Tee Shirt Crew Neck NULL NULL Hometown Tee's Tee Shirt Tank Top 24 216.00 Hometown Tee's Tee Shirt V-neck NULL NULL State House Active Wear Sweatshirt Hooded Sweatshirt 48 1152.00 State House Active Wear Sweatshirt Zipped Sweatshirt 48 1152.00 State House Active Wear Tee Shirt Crew Neck NULL NULL State House Active Wear Tee Shirt Tank Top NULL NULL State House Active Wear Tee Shirt V-neck 60 840.00 A star join is a multi-table join between one single “fact table” and several “dimension tables.” Pictorially, the fact table is at the center of a star, and the dimension tables are the points of the star, arranged around the central fact table. The fact table stores a large number of rows, each containing a single fact; for example, in the ASADEMO database the sales_order table contains over 600 rows, each containing the record of a single sale. The dimension tables store information about attributes of those facts; for example, the customer table contains the name and address of the customer who made the purchase. 94 Chapter 3: Selecting Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. Each dimension table is related to the fact table by a foreign key relation - ship, with the fact table as the child and the dimension table as the parent. For example, the sales_order table has foreign key relationships with three dimen - sion tables: customer, employee, and fin_code. The employee table contains more information about the salesperson who took the order, and the fin_code table has more information about the financial accounting code for the order. Dimension tables are usually much smaller than the fact table; in the ASADEMO database there are three times as many rows in the sales_order fact table than there are in all three dimension tables put together. Dimension tables also tend to be highly normalized; for example, each customer’s name and address is stored in one row in the customer table rather than being repeated in multiple sales_order rows. Star joins are used to denormalize the tables in the star by gathering data from all of them and presenting it as a single result set. For more information about normalization, see Section 1.16, “Normalized Design.” A star join may be represented as a FROM clause where the fact table appears first, followed by a series of INNER JOIN operators involving the dimension tables. The ON clauses on all the joins refer back to the first table, the fact table. Following is an example that selects all the sales orders in a date range, together with information from the customer, employee, and fin_code tables; the sales_order table is the central fact table in this star join. SELECT sales_order.order_date AS order_date, sales_order.id AS order_id, customer.company_name AS customer_name, STRING ( employee.emp_fname, '', employee.emp_lname ) AS rep_name, fin_code.description AS fin_code FROM sales_order INNER JOIN customer ON sales_order.cust_id = customer.id INNER JOIN employee ON sales_order.sales_rep = employee.emp_id INNER JOIN fin_code ON sales_order.fin_code_id = fin_code.code WHERE sales_order.order_date BETWEEN '2000-01-02' AND '2000-01-06' ORDER BY order_date, order_id; Here is the result of the star join, which effectively “denormalizes” four tables into a single result set: order_date order_id customer_name rep_name fin_code ========== ======== ===================== =============== ======== 2000-01-02 2131 BoSox Club Samuel Singer Fees 2000-01-03 2065 Bloomfields Samuel Singer Fees 2000-01-03 2126 Leisure Time Rollin Overbey Fees 2000-01-06 2127 Creative Customs Inc. James Klobucher Fees 2000-01-06 2135 East Coast Traders Alison Clark Fees Chapter 3: Selecting 95 Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. [...]... CURRENT TIMESTAMP? It’s not fair, however, to make fun of legacy artifacts like TODAY(*) and weird Transact -SQL abominations like CONVERT() One of SQL Anywhere s strengths lies in its rich variety of built-in functions, all explained quite well in the SQL Anywhere Help file This section presents some of the most useful, starting with (in the author’s opinion) the top 15 in alphabetic order: Table 3-1... If X contains 0, the predicate returns TRUE If X contains 1, the predicate returns FALSE Note: TRUE, FALSE, and UNKNOWN are actual SQL Anywhere 9 keywords representing boolean or truth values Unfortunately, however, there is no explicit BOOLEAN or TRUTH data type in SQL Anywhere 9 You can’t declare a variable or column as BOOLEAN, so you can’t directly store the value of a in a... '12345', '12345', '12345', 2 ) AS 2 ) AS 2, 3 ) AS 2 ) AS a, b, c, d; Here are the results: a b c d ==== ==== ===== ====== '12' '45' '234' '2345' Note: All string functions in SQL Anywhere start counting string positions at 1, not 0 This is SQL, not C; there are no zero-based offsets or zero-byte string terminators The LENGTH function is another string manipulation building block; it returns the current length... in SQL Anywhere 9; the number varies depending on whether you count functions like REPEAT() and REPLICATE() as being different (they aren’t) One book can’t do them all justice, and frankly, some of them aren’t worth the effort; how much can you say about NOW(*) other than that it returns CURRENT TIMESTAMP? It’s not fair, however, to make fun of legacy artifacts like TODAY(*) and weird Transact -SQL. ..96 3.7 Chapter 3: Selecting SELECT FROM Procedure Call A SQL Anywhere stored procedure can return a result set, and that result set can be treated just like a table in a FROM clause ::= [ "." ] "(" [ ... "." a reference to a SQL variable integer, exact numeric or float numeric literal see in Chapter 1, “Creating” The syntax of an is more complex than it has to be to satisfy the needs of a select list item That’s because expressions can appear in many other places in SQL, and some of these other contexts place limitations on what... limitations on what may or may not appear in an expression In particular, there are three kinds of expressions defined above: n First, there is the full-featured , which includes everything SQL Anywhere has to offer That’s the kind allowed in a select list, and that’s what this section talks about n The second kind is a , which has everything an has except for... unknown For example, if X contains NULL, neither of the comparisons X = 0 or X 0 is TRUE Neither of them is FALSE, either; they both return UNKNOWN Note: You won’t find “boolean expression” in the SQL Anywhere Help — look for “search condition” instead The term “search condition” implies a repetitive act, which may apply to the WHERE clause but not to a simple IF statement, and that’s why this book... You can use alias names just like cell names in a spreadsheet to build new expressions from the results of other expressions without repeating the code for those expressions This feature is unique to SQL Anywhere: the ability to define an alias name and then refer to it somewhere else in the same query; e.g., in another select list item or in the WHERE clause 3.10.1 IF and CASE Expressions The IF and... UNKNOWN results according to the following “truth tables.” For example, if a results in TRUE, then NOT is FALSE Note that you cannot actually code “NOT TRUE” in SQL Anywhere; the following tables are simply a shorthand for explaining what happens when you code something like “NOT X = 1”: NOT =========== NOT TRUE NOT FALSE NOT UNKNOWN Result ====== FALSE TRUE UNKNOWN . and Compatibility of Transact -SQL Outer Joins” by G. N. Paulley, 15 February 2002, iAnywhere Solutions Technical White Paper, Document Number 1017447.) 3.6. join among tables that exist in the ASADEMO database that ships with SQL Anywhere Studio 9. Here is the schema for the four tables (customer, product,