> > > 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.

If I had some spare barf, I would throw it on auto-inc fields ...

Bah. Did you ever notice the workarounds other systems have to
actually get the values of an auto-inc field? Heck, MS SQL has TWO
functions to get them and they may or may not return differenent
values depending on the context and multiple users "using" the table.

> 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?

The problem is not the lack of auto-inc fields, the problem is the
lack of intelligence of people expecting auto-inc fields to exist
in database systems.

> > > 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).

This isn't the case with expression indices or case-insensitive collations.

> > > 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?

Yes. That's why it's a "domain" and not a "datatype shortcut".

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

Domains aren't just other names for datatypes. It's a "domain", hence,
the ability to add a check constraint.

> > > 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.

Improved in Fb 2.

> > > 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.

With regards,

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com