> > There's a difference between generating the script and being
> > ABLE to insert BLOB values like this. The latter is missing,
> > but it would allow you to insert a JAR.
>
> As I say - I never felt a need to insert BLOB contents as text (except
> the SUB_TYPE 1, but that works anyway). And what can be its purpose
> except generating a script? Applications can insert BLOBs in more
> efficient way via prepared statements.
>
> But supporting standard is a strong argument and I'm not going to
> argue againt it.
>
> > If Firebird would understand the X'<hex values>' syntax, any tool
> > could execute such a script.
>
> 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.

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

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