On Fri, 14 Oct 2005 11:08:36 +0200, Martijn Tonies wrote:

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

I worked as a DBA in MSSQL. The documentation of the functions that
treat auto-inc fields allways looked terrorizing... Generators are MUCH
more safer and reliable.

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

Agreed. Even Oracle have sequences. Auto-inc is ok in Paradox and
Access... But in a decent RDBMS?

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

Cool. ;-)