masotti wrote:

>> But returning to CHAR ... If I configure that field as CHARACTER SET
>> > OCTET I
>> > should be able to simply handle the hex2bin output? I'm just about to
>> > dive into
>> > tidying that particular bodge up as currently I'm using CHAR(16) and just
>> > storing the hex:)
>
> Storing the value as a parameter should work, i.e. something like
>
> ibase_query ("UPDATE TABLE SET FIELD = ?", hex2bin
> ("65f0e300a96578616d706c6520"));
>
> Indeed FB 2.5 has hex literal support, i.e. (from RN)
> select x'deadbeef' from rdb$database
> select 0x10, cast('0x0F0000000' as bigint) from rdb$database;
>
> so instead using hex2bin()... (AFAIU it's not portable to other DBs)
> I didn't check, but I would expect that IBExpert should show correct
> binary data with connection CHARSET NONE.

I'm running UTF8 since we are logging internet traffic so the content is best
handled as that. It's the piwik analytic package which is working nicely in it's
cobbled form, but I now need to tidy the bodges ;)

> Selecting data, that I see that as a tricky part.
> UUID_TO_CHAR() shouldn't help, as, AFAIU, you've not UUIDs to store.
> So you'll have a binary data in a PHP var, and only unpack() perhaps
> should help.

The existing MySQL version is using hex2bin and bin2hex in the code so I want to
drop back to running with that as well. They are generating a 64bit ID for
'user' and 'user config' which would be nice as a BIGINT instead, but CHAR(8)
will do for now.

--
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php