On 4 May 2010, at 1:45am, Luciano de Souza wrote:

> Suppose I have a file called "audio.wav" and I want to store it inside a 
> database. If I correctly understood, I could create a table like that:
> 
> create table test (
> id integer primary key,
> name text not null,
> file blob not null
> );
> 
> I have never dealt with blob fields, so perhaps I need to read something 
> before. But I don't know where? It is not only a doubt about Sqlite, but 
> mainly about blob files.

SQLite handles BLOB fields the same as the other databases: they're 
variable-length fields which are guaranteed safe for any contents at all: null 
characters, escape codes, quotes, 0xFF characters can appear anywhere in the 
field.

> Is it simple to embed "audio.wav" in the database? After doing it, I can 
> delete the original file, knowing that inside the database there is not only 
> the reference to file, but the own file? And how to save it again in a file?

Yep.  You've got the right idea: store the filename in a text field and its 
contents in a BLOB field.  Your only problem is making sure that you always 
handle the contents as data and never accidentally as text.  Handling contents 
as text risks having zero-byte termination problems.

> What I imagine is that we need a handle for the file, we call a Sqlite 
> function with this handle and get a pointer wich we save in the blob field. 
> Likely there is a function to do the opposit operation.

I'm not sure whether you have this bit right.  SQLite does not understand files 
or file handles at all.  A BLOB field contains bytes (octets), any idea that 
those are the contents of a file are your own problem.  If you want to use a 
BLOB to represent a file it is the responsibility of your own software to read 
the bits from the original file and store them in the BLOB field, then to 
reverse the process when you want the bits again.  You can do this all at once 
by binding a BLOB like any other type of field, or you can use the special 
routines that handle a BLOB handle like a file handle like this:

http://www.sqlite.org/c3ref/blob_write.html

If you're just handling short sound files there's no need to do it gradually: 
just read the whole thing in one go.  The special routines are for cases where 
you might run into memory capacity problems or need to make sure that a single 
operating doesn't take too long.

Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to