> > > > 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

Yes, nasty ... :-/

Would this include an API change for the actual client, or only a
change from client-to-server?

With regards,

Martijn Tonies
Database Workbench - tool for InterBase, Firebird, MySQL, Oracle & MS SQL
Server
Upscene Productions
http://www.upscene.com
Database development questions? Check the forum!
http://www.databasedevelopmentforum.com