On Jan 5, 2007, at 11:32, Vlad Horsun wrote:

>>>> We evaluated SQL Server X for our embedded engine rejected it
>>>> because:
>>>>
>>>> - The database size has been crippled to 2G
>>>> - The installer requires .NET (and installs it).
>>>> - The footprint is 50G
>>>
>>> How much?
>>
>> Yes, 50Gbytes. But the hands-down winner was Oracle XP weighing in
>> at a CD-busting 600+Gb!
>
> Do you see the difference between MB and GB ?

No, I didn't ;-) Sorry about that - I meant Mb of course. The 2Gb
file limit is correct, however. And while I am mentioning Oracle XP,
it has a 4Gb limit.

>> Round, Sign, Sin, you name it. So for our calculations, we have
>> to wrap each one in a
>>
>> (CASE WHEN arg is NULL THEN CAST(NULL AS result_type) ELSE func(arg)
>> END)
>>
>> which I am sure wreaks havoc on any indexing we may have defined.
>>
>> (Gotta love those typed NULLs too...)
>
> Do you heard about BY DESCRIPTOR parameters ?
> May be you want to take a look on supplied fbudf library ?

Ah, I HAD heard of this, but it looks like we are using functions
from the ib_udf library which are not defined this way. But thanks
for the pointer - I shall see what we can do in the way of replacing
ib_udf with fbudf to reduce this problem.

> ...
>> BTW, If I am wrong about this and there IS an easy fix. I'd love to
>> know about it. I have a major work item coming up in the next 6
>> months to deal with this issue and I am not looking forward to it...
>> (And if any developer wants to send me an estimate on what it would
>> take to add this, I'd be very interested in looking at it.)
>
> Ask Adriano for this

Will do - thanks.

Incidentally, I apologise if this came across as overly negative.
Generally speaking, we are very happy with Firebird as an embedded
engine. Part of my job, however, is to be (sometimes painfully!)
aware of the subtle differences between 9+ different SQL engines. So
when I am doing comparisons like this, every little wart is magnified
because I know how several other engines do the same thing "better".
That does not mean that FB is "horrible" by any means, but I do think
it is good to point these things out - especially in a thread that
started out comparing FB to PG.

I should add that our use of FB is unusual in that it has to "look
like" ALL these other engines as much as possible. The fact that I
was able to get so close is really a tribute to the quality of the FB
engine. The only really big issues we have at the moment are the
derived collations problem mentioned above and merge joins for outer
joins. Everything else is pretty minor.

________________________________________________________
Richard Wesley Senior Software Developer Tableau
Software
Visit: http://www.trytableau.com/now.html