That Supports the Addition of New Database Objects Then You Probably Don't Need to Use SQL Expressions Since All of Your Database Field Manipulation Can Be Done in The

8/9/2019 That Supports the Addition of New Database Objects Then You Probably Don't Need to Use SQL Expressions Since A

1/10

Many of us have questions about SQL Expressions, however, Crystal Decisionsdocumentation is noticeably scarce on this topic. I hope that the following FAQaddresses your primary questions:

Q: What is a SQL Expression?A: A SQL Expression is a user defined field (such as a Formula or Parameter field). Theability to create a SQL Expression was added in Crystal Reports 7.

Q: How is a SQL Expression different than a Formula field?

A: There are many ways in which a SQL Expression differs from a Formula field:

1) The only functions available to a SQL Expression are database-specific functions asopposed to the common Crystal or Basic Syntax functions which are available in aFormula. The exact database functions available to you are determined by your database(SQL Server, Oracle, etc...) and your database driver (Native, CR-supplied ODBC andThird Party ODBC drivers).

2) The only fields available for use in a SQL Expression are true database table fields.You cannot incorporate Crystal functions, Parameters or Special Fields into a SQLExpression like you can in a Formula.


2/10

3) You cannot use Crystal or Basic Syntax (If-Then-Else statements, for example) in aSQL Expression. You can only use the database-native function syntax such as theOracle Function ADD_MONTHS(D,N) which returns the Date (D) plus N months.

4) SQL Expressions are always handled on the database whereas Formulas are handledon the client. If you were to review your Report SQL (Database|Show SQL Query) youwould see that the SQL Expressions are present in the Select clause of your SQLStatement.

Q: Why would I want to use a SQL Expression instead of a Formula?

A: The best reason I can think of for using a SQL Expression instead of a Formula fieldis to improve Report performance. Let's look at the following example:

Scenario:You have been tasked to build a report with From and To Date Parameters. Since your users hate typing Dates in standard Crystal Syntax (Date(YYYY, MM, DD)), your bosshas mandated that the Date values entered be Strings in the 'MM/DD/YYYY' format.

You have created {?From_Date} and {?To_Date} parameters based on String Values andmasked, as requested. Unfortunately, your Date fields are actually Date Values and areincompatible with String values. You can handle this a number of different ways inRecord Selection Criteria Directly or Indirectly with a Formula:

//Record Selection Criteria - Direct Method 1{Table.Date_Field} In Date(Right({?From_Date},4), Left({?From_Date},2), Mid({?From_Date}[color blue,4,2)) to Date(Right({?To_Date},4), Left({?To_Date},2), Mid({?To_Date},4,2))

//Record Selection Criteria - Direct Method 2ToText({Table.Date_Field},'MM/dd/yyyy') In {?From_Date} to {?To_Date}

//Record Selection Criteria - Indirect Method{@Date} In {?From_Date} to {?To_Date}

Where @Date is a formula defined as follows:

//@DateToText(ToText({Table.Date_Field},'MM/dd/yyyy'))

Whichever method you choose, your Record Selection Criteria won't be evaluated untilall records have been returned. Depending both on the size and integrity of your databaseand your machine's processor, RAM and Hard Drive space, you could be in for a very


3/10

long wait. Please note that the following SQL Statement (based on the last example)does not contain a Where Clause:

SELECT"TABLE"."DATE_FIELD"

FROM"DATABASE"."TABLE" "TABLE_NAME"

If you were to create a SQL Expression as follows (Oracle 8i Native Driver in thisexample):

//%DateTO_CHAR("TABLE"."DATE_FIELD",'MM/DD/YYYY')

Then you could use it in your Record Selection Statement as follows:

//Record Selection using a SQL Expression{%Date} In {?From_Date} to {?To_Date}

In this example, the Record Selection Criteria is passed to the Database and is, therefore, processed on the Server. This could result in a very significant performance increase.Please note that the Customized Parameter Selection is passed to the Database in theWhere Clause of the following SQL Statement:

SELECTTO_CHAR("TABLE"."DATE_FIELD",'MM/DD/YYYY')

FROM"DATABASE"."TABLE" "TABLE_NAME"

WHERETO_CHAR("TABLE"."DATE_FIELD",'MM/DD/YYYY') >= '11/01/2001' ANDTO_CHAR("TABLE"."DATE_FIELD",'MM/DD/YYYY')


4/10

If you, as a Report Writer or Developer, have the skills to create database objects andhave the necessary level of database permissions and are in a development environmentthat supports the addition of new database objects then you probably don't need to useSQL Expressions since all of your database field manipulation can be done in the

database object you create.

Generally speaking, however, if you can substitute a SQL Expression for an equivalentFormula (based on your available SQL Functions) then it is appropriate to do so. Asexplained above, this is especially important when it comes to your Record SelectionCriteria.

Back to Business Objects: Crystal Reports 1 Formulas FAQ IndexBack to Business Objects: Crystal Reports 1 Formulas ForumMy FAQ ArchiveEmail This FAQ To A Friend

Print This FAQMy ArchiveMy FAQ Archive

Join | Jobs | Advertise | About Us | Contact Us | Site Policies

Copyright 1998-2010 Tecumseh Group, Inc. All rights reserved.Unauthorized reproduction or linking forbidden wit


5/10


6/10


7/10


8/10


9/10


10/10

Documents

That Supports the Addition of New Database Objects Then You Probably Don't Need to Use SQL Expressions Since All of Your Database Field Manipulation Can Be Done in The