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