World: r3wp

So, the error in one small message: 

>> sql ["select * from person where guid = ?" #"a"]

** Script Error: length? expected series argument of type: series 
port tuple bitset struct
** Where: switch
** Near: *bind-text sid i val length?

If you're using CONNECT/direct then char is not an available datatype 
(and you would have had the same problem trying to insert a char). 
What does the raw data look like? I suspect it is: {#"a"}

No, actually it is something like "abcdef", I had one 'first too 
many in my code. That was the problem.

It''s just that I stumbled about the error, and didn't know what 
to make out of it. At least at first.

Is it somehow possible to encrypt the content of databases?

Ok, there seem to be some companies that offer special SQLite DLLs. 
Ashley, maybe you can have a look to see if the DLL interface is 
compatible? I think there shouldn't be big changes necessary. Take 
a look at: www.sqlcrypt.com

It's just adding two APIs to SQLite.

I'm going to check it out.

You could always encrypt selective columns client-side (e.g. sql 
reduce ["insert into t values (?,?)" key encrypt string])

Yes, but for querying I need to encrypt the data as well to be able 
to select it. Don't know if this is a big performance hit.

If it's only TEXT types you need to encrypt then we could always 
add a /secure refinement to CONNECT that would force encrypt / decrypt 
on all TEXT bind variables. Performance wouldn't be too bad as values 
would only be encrypted [once] on INSERT and SELECT, the actual query 
(which could potentially hit millions of rows) would be comparing 
encrypted strings and would only need to decrypt strings that form 
part of the result set. Very similiar to the overhead that MOLD/LOAD 
currently incur when not using the /direct refinement.

Does sqlite have a "like" command for searching within text fields 
?

If so, then searching on text fields would be problematic if they 
were encrypted.

I was thinking of encrypting my own text fields for security, but 
came across this little problem.

Yes on both counts. Really depends on what kind of data needs to 
be encrypted; if it's passwords and personal information that is 
indirectly referenced (i.e. on / by other key column(s) ) then client-side 
encryption makes sense.

I am not sure it is wise to encrypt all text fields .... usually 
you may require to encrypt password field or something like that, 
but all fields at once? Maybe if it really makes implementation simpler 
....

You'd better ask Robert how wise he is.

IMO encryption should be on a lower level, on the file level. I don't 
want to care about using encryption in my application, I just want 
to set a flag that the database file gets encrypted.

Background: I'm building up a massive benchmark database for cost 
data. And I need to encrypt all information in it.

I tried to use: CREATE TABLE IF NOT EXISTS but I get an error if 
I use this line and the table already exists.

The SQLite docs say:

 If the optional IF NOT EXISTS clause is present and another table 
 with the same name aleady exists, then this command becomes a no-op.

Did anybody tested to open sqlite.r generated databases with a database 
manger? I can't. In one tool I can see the database but not tables, 
even I have created one.

And if I use the TABLES command I get:
>> print tables

material CREATE TABLE material (_id INTEGER PRIMARY KEY AUTOINCREMENT,_version,_benchmark,_prev,_next,_product_id,name,price,pcdl,pudl,netto,nudl,scrap,loss,process_loss,scrap_re

cycle_rate,scrap_recycle,srcdl,srudl,process_loss_recycle_rate,process_loss_recycle,plrcdl,plurdl) 
sqlite_sequence CREATE TABLE sqlite_sequence(name,seq)

The docs state that I get beck the number of columns and rows... 
Any idea?

Using sqlite.r I can acess the table and get back my values.

And I can't get back the columns name. sqlite/columns returns an 
empty block.

anybody tested to open sqlite.r generated databases with a database 
manger?
 Not sure what you mean here. The following works fine for me:

	c:\> sqlite3.exe my-db.db

docs state that I get back the number of columns and rows
 ... no longer the case (docs need to be updated)


Most efficient way to get number of rows is sql "select count(*) 
from my-table"


Number of columns can be found by: (length? describe "my-table") 
/ 6

I can't get back the columns name

 ... use the DESCRIBE command, or CONNECT/info (which then populates 
 sqlite/columns and sqlite/widths for every query; or alternatly, 
 set sqlite/col-info? true / false for a particular query).

A simple rows function:

	set 'rows make function! [
		"Return row count."
		table [string!]
	][
		first sql/flat/direct reform ["select count(*) from" table]
	]

just add it to the body of the sqlite context.

Thanks.

WRT encryption. I found one implementation (you need to buy a license) 
that supports transparent encryption. IIRC I posted the link some 
time ago. I will have a look at the C code and there at the storage 
stuff to see how hard it is to add an AES encryption of storage pages. 
IMO it can't be that hard.

0.2.0 available at: http://www.dobeash.com/SQLite/


Incorporates minor fixes / changes discussed since 0.1.9, with documentation 
updated to match (some content was also moved from the old Driver 
Guide to the new User Guide).

I was just reading the User Guide on that site and I noticed that 
there were some parts of the docs on the DESCRIBE function that you 
seemed to have some questions about, particularly the meaning of 
some of the returned columns. (Sorry if I am in error about that.)


- On the table column listing, the notnull column refers to whether 
you are allowed to insert a NULL in that column. The pk column tells 
you whether the column is a primary key. Primary keys in SQLite are 
always integer and are their way of doing autonumber fields.


- On the indexes listing, a unique index also makes sure that the 
combination of values that the index applies to won't be duplicated 
in the table.

Thanks, I've updated the page (replacing my shorthand for a flag, 
?, with the word flag). If anyone has a description of the columns 
for FKeys just holler and I'll add it in.

I'm not sure it matters yet. SQLite doesn't check foreign key constraints 
yet, so any such constraints are just documentation right now.

Still, here they are (best estimate based on reading the SQLite C 
source):

- id: The index of the foreign key in the list of foreign keys for 
the table, 0-based (integer)

- seq: The index of the column referenced in the foreign key, 0-based 
(integer)
- table: The name of the referenced table (string)
- from: The column name in the local table (string)
- to: The column name in the referenced table (string)

id: Isn't ID only unique for every table? Yours read like ID is unique 
for the complete database.

No, this is a diagnostic table generated by a pragma statement. It 
isn't really a table internally. Still, the key for this "table" 
is (id,seq) and it is generated by a pragma that takes the table 
name as a parameter, so it is a seperate "table" for each real table.

It really is a linked list internally - that's why I called it that 
:)

Each "row" of the "table" refers to a column referenced by a foreign 
key that may refer to more than one column.

And a table may have more than one foreign key.

And all of these foreign keys are currently meaningless because they 
aren't currently checked by SQLite - they are just documentation.

Still, you could make a tool that actually read these foreign keys 
and checked them externally if you want...

IIRC you can even access those internal tables of SQLite and query 
them.

Well, for the most part this database metadata isn't really stored 
in tables in SQLite. Instead queries about the metadata are generated 
from internal structures when needed, by pragma statements. Still, 
the effect is the same.

It's kind of cool really when you read how this is done. I guess 
things can be a lot more interesting for a single-user embedded database 
engine. You can see where SQLite gets its high performance.

I have to take a look at the C code. But #pragma stuff is compile 
time...

No, not C pragma, a set of PRAGMA statements that SQLite extensions 
to SQL, for settings and diagnostics.

...that _are_ SQLite extensions...

Check http://www.sqlite.org/pragma.html

The statement that returns the result set we were talking about is:
    PRAGMA foreign_key_list(table-name);

Thanks, updated page.