--- In Firebird-Architect@yahoogroups.com, "Leyne, Sean" <Sean@B...>
wrote:

>
> Tom,
>
> > 1. Lack of Internal set of system functions automatically available to
> > all databases. (These would be considered seperate, and *in addition*
> > to the good UDF support)
>
> Agreed, there have been higher priority items to be addressed before we
> tackled this.

IMO this item is a classic case of something that has stopped
(sometimes in their tracks!) the uptake of FB by new users and
companies. I sometimes wonder how popular FB would be if only three
items were attended to: internal system functions, case-insensitive
searching option + auto-inc fields.

Repeatedly declaring large 'system-ish' UDF scripts on a per-database
basis is daft (plus potentially buggy). Let's deal with this one and
for all - non?

Also, if a company cannot migrate easily to another DB then it just
ain't gonna happen. I don't like autoinc fields personally but they
have their place on occasion - and when you need them you need to a)
declare a generator then b) write a trigger. This is not what Joe
Public expects in this millenium - we haven't got as much time as
before. Can't we (behind the scenes) create a trigger (position -1)
with an internal generator name and a block on alter column?

> > 2. The ludicrous situation of having to create 'shadow' columns +
> > BI/BU triggers in order to provide case-insensitive searches.
>
> Firebird v2.0 allows for indexes to be defined based on expressions.
> Thus you will be able to define an index on "UPPER( Field_NAME)" and
> have the system use the index as appropriate.

Its a good improvement but it doesn't satisfy the need in question.
When users can't find some data (non-indexed) and I say "you need to
type it is exactly as you entered it" (ok - I'm exaggerating, there is
an UPPER() function but the truth is I don't want to incur a function
call for every row on a large table - esp. across the wire, precluding
use of indexes - if I don't have to).

>
> > 3. Domains *used throughout entire system* would be great.
>
> This has been discussed and there are a number of semantic issues
> related to using Domains.
>
> Domains support a larger definition than 'simple' data type, such as
> default and check/constraints. Are these 'extended properties' to be
> applied each time a SP is called?

I wouldn't have thought so. It's desirable for system-wide centralised
consistency for sp/trigger parameter and variable datatypes and
data-dictionaries.

> Additionally, Domains can be ALTERed. What is the impact of ALTERing a
> Domain on the related SPs?

It's a problem, but surely in the same way you can alter columns
(within allowable rules) this could be enforced in a similar manner.
Worst case means dropping dependancies and recreating.

> > 4. Views where you don't have to specify return datatypes.
>
> Please provide an example.

Competitors can surmise output datatypes directly from select
statements. It is a nice to have.

> > 7. Export DUMP options to SQL statements, XML, etc
>
> There are already a number of third-party tools (free) which do this.
> Why would the project 're-invent the wheel'?

IMO this should be part of the core (esp. dump to SQL) and not have to
be provided by 3rd party. New users will be surprised, then dismayed,
that this isn't provided.

By the time they go on to realise there are no 'system' functions, no
auto-inc datatype, no case-insensitive search switch they'll resemble
a water fountain.

Tom