It was used just to store JPG Logos of companies :)

Wherever they where used, IB_SQL shows

, LOGODATE TIMESTAMP
, LOGO BLOB( 65535, 512 )
, LOGOSIZE INTEGER

Don't worry, I'm retired and just keep myself busy
at times assisting finding problems :)

Best Regards
Hans

----- Original Message -----
From: "Jason Wharton" <supportlist@...>
To: <IBObjects@yahoogroups.com>
Sent: Tuesday, March 23, 2010 10:25 PM
Subject: Re: [IBO] development


> Geoff,
>
> It is VERY possible that IBO invokes default blob filter activity. I have
> implemented blob filters for all the pre-defined types that are above 1.
> If
> Hans is using a sub-type above one then IBO may steer the processing of
> his
> data through a filter of some kind.
>
> For example, the BLR subtype can be cast to TEXT sub-type and you will get
> a
> textual representation of the binary contents.
>
> Hans should NOT be using blob types greater than 1.
>
> Jason Wharton
>
> ----- Original Message -----
> From: "Geoff Worboys" <geoff@...>
> To: <IBObjects@yahoogroups.com>
> Sent: Monday, March 22, 2010 10:47 PM
> Subject: Re: [IBO] development
>
>
>> Hi Hans,
>>
>> Intermitted link problems (ongoing) here mean I have not been
>> able to respond exactly when I wanted (not to mention that
>> nasty subject of paid work ;-).
>>
>> Analysing the log from your precompiled executable reveals the
>> following:
>>
>> TABLE Records IBO FIB
>> INVENTORY 16101 6.375 16.047
>> LOGOS 106 21.047 6.063
>> MUDCOMPANIES 3058 20.485 7.39
>>
>>
>> Notice the two stand-outs? Those are both tables with large
>> binary blobs.
>>
>> Side Note: How did you create those blobs? When I tried
>> to create an equivalent table using Firebird 2.1 I get
>> this error from FlameRobin:
>> Engine Code : 335544569
>> Engine Message :
>> Dynamic SQL Error
>> SQL error code = -204
>> Data type unknown
>> Blob sub_types bigger than 1 (text) are for internal use only
>>
>> I changed the type to 0 and was able to proceed.
>>
>>
>> So the problem appears to be blobs. So I proceeded to copy the
>> LOGOS table across to my testing database and ran my two xfer_*
>> programs against it.
>>
>> I did not manage to speed up IBO... but I did manage to to slow
>> down FIBPlus:
>>
>> = = = xfer_ibo = = =
>> App Init Time: 16ms
>> Object Prepare Time: 78ms
>> Records Transfered: 106
>> Records Transfer Time: 21328ms
>> Transaction Commit Time: 594ms
>> Connection Close Time: 0ms
>> Application Run Time: 22016ms
>>
>> = = = xfer_fibplus = = =
>> App Init Time: 0ms
>> Object Prepare Time: 188ms
>> Records Transfered: 102010
>> Records Transfer Time: 20187ms
>> Transaction Commit Time: 672ms
>> Connection Close Time: 0ms
>> Application Run Time: 21047ms
>>
>>
>> Isn't that strange? So then I compiled your MaintArcs program
>> and it shows LOGOS transfer in just 9seconds.
>>
>> Hans is there any way to validate the logo blobs being
>> transfered to the server? I keep wondering about that subtype
>> 512 thing and whether FIBPlus and IBO are behaving differently
>> due to the subtype.
>>
>> --
>> Geoff Worboys
>> Telesis Computing
>
>
>
> ------------------------------------
>
> ___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or
> InterBase
> without the need for BDE, ODBC or any other layer.
> ___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info
> papers,
> keyword-searchable FAQ, community code contributions and more !
> Yahoo! Groups Links
>
>
>