Description Jeremy Lindop 2007-09-07 05:37:02 EDT

The following areas in which SQL dialects differ should be supported by the SQL Builder’s enablement framework:
•	Built-in functions and operators: Built in functions and operations should be defined as SQL model metadata supplied to the expression editor rather than being hard-coded in the editor. This will enable DTP adopters to specify the function and operator definitions for their own databases in the SQL model. A bugzilla enhancement request to add built-in function and operator metadata to the SQL model will be entered to support this.
•	User-defined functions: An extension point will be defined which allows DTP adopters to retrieve information about user-defined functions in whatever way is required by their own database. Alternatively, it may be possible to extend the sql model so that it covers user-defined functions.
•	User-defined data-types: An extension point will be defined which allows DTP adopters to retrieve information about user-defined data-types in whatever way is required by their own database. Alternatively, it may be possible to extend the sql model so that it covers user-defined data-types.
•	Variable handling – dialect variations in variable handling should be part of the SQL Builder enablement framework.
•	Complex dialect variations
o	Keyword variations
o	Syntax variations, e.g. COMPUTE
o	Datatype support
o	User-defined datatype support
In order to define how the SQL Builder can be made extensible to cope with complex dialect variations, a number of test cases should be selected and a detailed design be specified for how the SQL Builder might handle these cases through an extensibility framework.

Estimate: 30 days or more