> > > If Firebird would understand the X'<hex values>' syntax, any tool
> > > could execute such a script.

Agreed, this is a good and needed feature

> > True, but what's the point in it? Being able to dump database contents
> > into the text file and recreate it on the other server? What's wrong
> > with the backup then?
>
> Recreating a single table?
>
> Moving from another database system that DOES support the SQL
> standard on this one?
>
> Just export an "insert script" to add to another table?
>
> All sorts of uses, actually.

And more and more and more...

> > > If the Firebird client would understand a "FROM FILE" part, it would
> > > be able to load a file from the client and send it to the server as
> > > a blob? stream ...
> >
> > This does not belong to the client library. It is not the job of the
> > client library to interpret SQL being passed. Either application
> > before actually passing it to the server or database engine itself.
>
> I could go along with that ... but, debatable, since there's currently
> no decent way of importing files/blobs without the hex values syntax :-)

Show stopper here is our limit in 64K on single SQL statement text
length and input\output message length. And this is can't be changed
without an corresponding API change

Regards,
Vlad