At 09:32 PM 03-10-02 +0000, you wrote:

>Hmmm...
><ME THINKING TWICE>
>Ok, I could use a generator and simply read it's current value.
></THINKING>

SELECT MAX() and reading the latest value from a generator won't be
guaranteed to be the same in a multi-user environment...the latest value
from a generator may be used for an insert within a transaction that hasn't
committed yet - and might be rolled back. Generators themselves are
outside transaction control...

>Sometimes the best answer is another question. Thanks Sean!

Sometimes the best answer is an answer, too. :-)

>Do you have any clue about my other question? The fact is that we use
>a product called "Autodesk Mapguide" that generates vectorial maps.
>Some information layers may be retrived from database. The map server
>queries the database with something like:
>
>SELECT <some col>
> FROM <some table>
> WHERE <lat col> BETWEEN <lat min> AND <lat max>
> AND <lon col> BETWEEN <lon min> AND <lon max>
>
>We use Oracle as our RDBMS, but I would like to use FB as a
>development platform (Oracle may be expensive to license and
>administer, but it *is* the best performing DBMS I've ever used). I
>was wondering how the index compresion could negativly affect the
>above query. Any pointers would be welcome.

If you have two-way indexes on each of <lat col> and <lon col>, the engine
will seek BETWEEN ranges intelligently. One thing that will detrimentally
affect the speed of indexed searches is if any of these indexes has most of
its index values concentrated in a small number of actual values. What
types are these data, i.e. is there enough granularity in each individual
value to ensure a reasonably low frequency of duplication? Latitude and
longitude matter in binary trees, too. :)

An important factor in the speed of searching is how effectively you can
limit the "catchment" of searches through your WHERE criteria. In the
example above, perhaps by limiting another indexed column (where... AND
LOCALE starting with 'A' AND ADATE > CURRENT_DATE - 10) or whatever.

heLen