Christian Stengel wrote:

>Hi Jim,
>
>
>
>>The way to do a fast load is to load the data with indexes disabled
>>then
>>enable the indexes. The indexes will be built using a "fast load"
>>scheme from a sorted data stream, which is much faster than incremental
>>index updates. This does not require additional database support.
>>
>>
>>
>
>Will this be faster than in firebird? I am doing that currently this
>way.
>
>

Nothing to be gained there. As a number of people have suggested,
running the database embedded (Firebird 1.5/2.0) or "file shared" in
Vulcan (the same thing but with sharing) will help a lot.

>
>
>>>
>>>
>>That's what UDFs are for. Use them.
>>
>>
>
>OK. But internal functions would be nicer - easier to handle, you can
>be shure, that they are available on all platforms ...
>
>

There are an infinite number of possible functions. And more possible
functions than names, which causes strife among developers. Things that
are clearly common tend to make it into the udfs shipped with the
product. Frankly, I don't see metric conversions making that list,
particularly since Firebird is most popular in places that are metric.

>
>
>Great. In FB 1.5.2 I can edit a .gdb file with vi and see the strings
>unencoded
>
>

I suggest you don't save it. It won't be the same with line feeds deleted.

Run length encoding is nothing more than compressing multiple
occurrences of like bytes. It works well on trailing blanks and nulls.
It doesn't do much at all for anything else.

>Can the filemanager easily be exchanged in Vulcan (e.g. without the
>need of recompiling the whole engine?).
>
>

No, but it could be. The external file manager was designed as a plug
replaceable module with different modules for VMS and the civilized
world. If somebody wants to do the work, it could be made loadable. At
the moment, it isn't.

>>application that uses RMS. It is not intended to every be an
>>alternative record storage format.
>>
>>
>
>Yes. I know that. But when you have to deal with 35.000.000 records per
>day from one source - you have to be creative - and one aproach could
>be:
>
>
>

OK, I'll concede that 35 million records a day is a fair bit.
Creativity is definitely going to be required. Have you considered
improbability quanta?


[Non-text portions of this message have been removed]