AltME groups: search

If anyone has some other patches, let publish it here. I'll wait 
a few more days before closing the beta state and declaring this 
version the new stable one.

Doc, what would be needed for the driver to work like Command driver? 
I mean the ability to db-conn: first db, and have multiple connections/channels 
to have available?

You already can have several connections opened at the same time 
with the current driver. I don't see the benefits of the /Command 
way. If you really need to have exactly the same behaviour, I guess 
that you have to overload the 'first function in my code and return 
a new port! using  the connection port  as 'sub-port.

I need one that's integrated into Rebol. Didn't took a look at it. 
Just thought it makes sense to have a protocol like DocKimbel's and 
re-use it with different databases (R-ODBC)

Uniserve is one of our base framework  (both for internal use and 
for our customers), so we're working on it actively.

I'll release it as soon as I find some time to update the docs and 
package it.

Doc,  I'm not sure if you've got this yet or not,  but we found a 
bug where the 'read-packet function's buffer was not getting expanded 
properly which was causing it to truncate some of our data.  To fix 
this problem then we added a local variable and added these lines:

tmp: pl/cache
pl/cache: make binary! pl/buf-size
system/words/insert tail pl/cache tmp

after this line:

pl/buffer: make binary! pl/buf-size: packet-len

Ok, I've found a workaround for this problem. I still have a 1045 
User deny random error to fix (almost done) and make a new release 
tomorrow. 1.0 official release is now very close.

After tracking down the problem, here's the explanation of the random 
1043 (bad handshake) and 1045 (access deny) error on connecting to 
the server :

thanks for the explanation and for your research. the terminating 
character strategy looks like fundamentally flawed, because it causes 
problems of this kind too often to be considered useful, at least 
in my opinion

I agree, I never use this approach when I design a new protocol. 
It leads to error and it's harder to handle on the receiver side 
because you don't know how much data you're waiting for.

So v 1.0 will have to live with those occassional errors? If so, 
we should go for 1.0 and claim it is a feature, not a bug :-)

With v3.x.y servers, there's still sometimes connections errors 1045 
that shouldn't happen. I guess that's related to some encryption 
implementation difference between my client and v3 servers. Workaround 
for this, is catching error! values when connecting and retrying 
the connection if the user/pass is fixed and should be able to connect 
to the server (proper right set in 'mysql' tables).

There is one email on ml, reporting still having problems with latest 
version - his name is Alain Goye, and he says that his error is not 
random, but deterministic, dunno what he means, Anton trying to find 
out more info ...

Doc, one forgotten probe probably ... go look into do-handshake function 
and the part where you send-packet port probe rejoin [] ... the probe 
should not be there probably ...

Tried to reproduce Alain's problem without success. I've even created 
new users with server v4.1-16 and can log in without any error.

with 1.0.3 and MySQL 5.x.x

This sounds just like the issue we were talking about in SQLite group. 
You probably need to copy the results and maybe also clear the strings 
returned by the query.

I'm not sure how to do that... I 'insert a query to a port and 'copy 
the result back out from that port... I can't control that, can I?

Remember that COPY actually calls the COPY function in the scheme 
handler. (probably, I haven't looked at MySQL scheme).
Therefore maybe what you want is actually:

	result: copy copy port


The theory being that the first COPY provides you with the result 
string from inside the scheme handler (but the scheme still hangs 
on to it), and the second COPY works as usual in rebol (actually 
makes a copy).

which mysql version? I've only seen it on 4.1 and up

try changing the  Privileges to 'No password' for the user and see 
if the error still exists?

I've just realised that I' have old_passwords set on and am using 
the latest version of Mysql-protocol.r :-(

Thanks for your help, Yek Soon and Petr.

dumb question.. is this a valid query?

select i1.id,i1.ip,i1.session from isa i1,isa i2 where i1.ip=i2.ip 
and i1.session<>i2.session order by i1.ip
about 70'000 records in isa
running this query seams to crash/block the mysql server..

not a well constructed query. unless my mental parser isn't working. 
You are asking for each and every row where it doesn't match the 
current row... now I don't think that is your true intent ...

Ok, so you mean MySQL Administrator (and not the mysqladmin.exe command 
line tool).

Tried creating a user using that tool under WinXP and OSX, then I 
tried connecting with mysql-protocol.r => no problem...

then I tried to turn them off again through the GUI and it didn't 
change.

Could you activate : trace/net on before using mysql:// and show 
me here the server information retrieved by the driver.

I didn't do that, so it must have been done with new passwords. I 
could immediately overwrite the old style password with the new style 
and it worked immediately

The server may try a reverse dns request on your IP when you connect 
and ends with a timeout after 60secs.

Good news : I've finally reached a very stable version of the mysql 
driver with v5+ servers ! The stability garanted only if using a 
database created with a v5+ server, copying old 3.x files in v5 server 
works but results in a big mess and unstable behaviour. Exporting/Importing 
v3.x data in v5 server using SQL flat files works very well (except 
for user with passwords, better recreate them in v5 directly).

copying old 3.x files in v5 server works but results in a big mess 
and unstable behaviour
 <--- is that because of MySQL or mysql-protocol.r?

I've just run a big stress test with 40'000+ requests generating 
around 2Gb of traffic without any trouble ! No bad handshakes anymore 
if you're using v5+ tables and new passwords.

there are times when the connection to the database won't wake up 
after hours of sleep and the application locks. this also happens 
with mysql-admin, but I wonder if it really is server or a client 
side problem.

Thank you. With the old protocol I would sometimes get  an error 
 (and exit from the program) when I inserted into a closed port. 
I will give these a shot.

I can see that mysql console has no problem in reconnecting where 
rebol and mysql-admin fail

and intense bugfixing sessions 4 days before releasing 1.0 :-)

I like async internally, and anyway I remember I had problems with 
the non-asyns async - I think sometimes it was not able detect if 
the client closed connection or something like that, and i have my 
async version of postgres I'm using. I want new build of Core with 
async and rebocodes so much:(

<Pekr>
Ashley, just wanted to ask and can't find rebdb group here ...


Isn't it possible to implement 'join? You once said that you will 
wait once RT adds RIF, but that will probably come who knows when 
- it is year and half late already. Do you think it would not be 
possible to proceed without RIF and switching to on-disk storage?


'join is really badly missing with rebdb and I am thinking switching 
to sqlite only because of that one feature. Once you have your data 
spread across many tables, it is difficult to work without it. Or 
how you do it?
</Pekr>

<Jaime>
Pekr. Join is relative easy to implement.


Just do a search on each table, and then create a new block by using 
the key that joins them.

foreach key table1 [
	values-table1: select key table1
	values-table2: select key table2
	append join-table reduce [values-table1 values-table2]
]

That is more or less the pseudo algorithm
</Jaime>

JOIN differs from SUB-SELECT where you want to aggregate the columns 
of more than one table, so:

	select a.col, b.col from a, b


cannot be refactored as a sub-select. There are two reasons why I 
have not implemented JOINs in RebDB [yet]:

1) Dramatic increase in code complexity

2) You can almost always do it more efficiently in REBOL as you *know* 
the data structures and desired result set *in advance*.


About the only time this does not work well [in RebDB] is where you 
have to pull the contents of more than one table across a network 
to derive a small subset as the result set. So while this SQL would 
not suffer:

	select a.col, b.col from a, b

this might:

	select a.key, b.val from a, b where a.key = b.key

depending on the size of b.

But, Petr, perhaps it would be good if you could show the operation 
and tables that you are having trouble with, and Ashley can help 
you find the best way. Maybe the performance will be more than you 
need, and the expression simpler in rebol.

It's called a "Pseudo-Relational Database" for a good reason. ;)


But in answer to Pekr's previous point; *you* can work out *how* 
to do that aggregation more efficiently than the limited AI of most 
RDBMS systems. I've worked at DB2 and Oracle shops where it was mandated 
that all JOINs be performed inline! SQL optimizers are not trivial 
to write, and the meta-data overhead (indexes, statistics, hints, 
etc) required to get them to make the "right" choices are often a 
false economy.

then, when you enter new order into 'orders, you simply assign it 
to company, by using and storing foreign key, so 'company-id ...

And now you have typical problem - you surely don't want your grid 
to show 'company-id, but 'company-name or other related data - but 
those are not present in 'orders database ...

that is imo correct design to simply avoid data inconsistency. Imagine 
if you would put 'company-name into 'oders, and later on company 
changes it's name a bit - you simply want that info to have stored 
only once ...

ok, here's my rebol odbc code for ADS (Advantage Database Server):

insert db-port trim/lines {

   SELECT DISTINCT ko.kodfyzak, fk.nazev, fk.ulice, fk.mesto, fk.psc, 
   fk.kodzeme, zk.land1, upper(fk.kodmeny),
                   upper(e.ico),

                   ko.kodfypri1, fp.nazev, fp.ulice, fp.mesto, fp.psc, fp.kodzeme, zp.land1, 
                   upper(fp.kodmeny)
                      
   FROM zakp_exp e

   INNER JOIN Kontjkv5 k5 ON k5.zakazka = concat(e.miv, left(e.czak, 
   6)) 
   LEFT OUTER JOIN kontrakt ko ON ko.ciskontr = k5.ciskontr

   LEFT OUTER JOIN firma fk ON fk.kodfirmy = ko.kodfyzak  AND fk.aktualni 
   = 'A'

   LEFT OUTER JOIN firma fp ON fp.kodfirmy = ko.kodfypri1 AND fp.aktualni 
   = 'A'
   LEFT OUTER JOIN zem zk ON fk.kodzeme = zk.kodzeme
   LEFT OUTER JOIN zem zp ON fp.kodzeme = zp.kodzeme
   LEFT OUTER JOIN delka_psc psc ON zp.land1 = psc.land1
   ORDER BY fk.nazev, fp.nazev
}

An example based on what you are trying to do with Orders, Items 
and Companies might be better to start with.

Stick to basic JOIN syntax in the form:

	select b.name, b.address
	from a, b
	where a.id = b.id
	and ...


those INNER JOIN and LEFT OUTER JOIN statements are unfamiliar to 
me and I get a headache just looking at them. ;)

Not sure if I'm off topic here.....But you can do pretty much everything 
in SQL without using JOIN. Though you may need UNION, subselects 
and WHERE.

Which makes for more portable SQL as JOIN syntax often used vendor-specific 
extensions to the SQL-92 standard.

maybe it is a pity rebol can't do union and join on more per record 
base, but per item base ...

Back to Pekr's JOIN problem. First, let's reformat the SQL into something 
more readable:


select o.order-id, o.date, o.amount, o.total, oi.item-id, io.item-price, 
oi.goods-name, c.company-name
from   orders o
,      order-items oi
,      companies c
where  o.order.id = oi.order-id
  and  o.company-id = c.company-id
  and  o.amount > 2000
order by c.company-name, o.order-id, o-item-id

Then break it down into discrete queries and wrap it in some loops:

blk: copy []

foreach [company-id order-id date amount total] sql [

 select [company-id order-id date amount total] from orders where 
 [amount > 2000]
][
	company-name: second sql compose [lookup companies (company-id)]

 foreach [item-id item-price goods-name] sql compose [select * from 
 order-items where (order-id)] [

  insert tail blk reduce [order-id date amount total item-id item-price 
  goods-name company-name]
	]
]

sort/skip/compare blk 8 [8 1 5]

The final [untested] solution is about as efficient as you can get. 
Adding JOIN support to RebDB so it can break the query down into 
similar steps is not a simple task. In all but the most trivial of 
cases you'd be better off coding it yourself.


What might be a good idea is to add something that lets you more 
easily specify the most common JOIN operation - master/detail with 
optional LOV (List Of Values) lookup(s). Your query is a classic 
example of this construct and it accounts for a surprisingly large 
number of queries.


The function would accept two queries, a master query (the orders 
table in your case) and a details query (the order-items table) and 
an optional block of column/LOV-table pairs (that perform substitutions 
such as company-name). The skeleton would look like:


 sql-join [master-query [block!] detail-query [block!] /order /lov 
 [block!] ]  [
		buffer: copy []
		...
		buffer
	]

and would be used as such:

	sql-join/order/lov [

  select [company-id order-id date amount total] from orders where 
  [amount > 2000]
	] [
		select * from order-items where %ID%
	] [8 1 5] [company-id companies]

Would this make things a tad easier?

yes, basically it is typical two cases - master-detail, and lookup!!!

IIRC MySQL docs join section describes very nicely the technique 
of optimisation. And after reading it some few monts ago I agree, 
that 'join is not trivial task at all, basically due to get it optimised. 
But you are right that most of the time those two mentioned cases 
are needed. The thing which complicates the optimisation part is 
- is your column a key? primary key? is it at least indexed? etc.

Ashley, sql-protocol generates the code used to extract and join 
the data is grouped in 2 functions :
- make-do-select
- make-do-loop

They receive the column list, the table list (a block of table/alias 
pair), the where code to apply and the database (the port).


If you provide these parameters and change the code to invoke RebDB 
fuction to get the data, you will have a basic join implementation 
for RebDB. You can use it and extend it for RebDB, if you want, I 
will be happy if you do so.

Thanks guys, I've had a good look at both implementations and I've 
got ideas from both for a future full JOIN implementation; but at 
the moment my master/detail code has come along nicely. I've now 
enhanced the db-select function to accept statements in these additional 
forms:


 select * from master joins [select * from details where &id] on id

 select * from master joins [select * from details where [all [master-id 
 = &id master-date = &date]] on [id date]


which works exactly like a normal join with the following differences:

	a) It can only join one table to another

 b) Detail columns are always joined to the right of master columns

 c) Table.column prefixes are not supported so all columns in the 
 join must be uniquely named


Apart from that you get all the benefits of db-select (can replace 
* with specific column combinations, order and group by on the final 
result set, etc) *and* it's significantly faster than even the raw 
REBOL code example I gave before (as the SQL is parsed once within 
db-select and all loop sub-selects are done in-line).

I've also implemented “lookups” with the following form:

	select * from table replaces id with name
	select * from table replaces [id-1 id-2] with [table-1 table-2]


which performs a highly optimized db-lookup for each replaced value, 
but has the following restrictions:


 a) The lookup expects lookup tables in the form [id label other-column(s)]
	b) Only single-key lookups are supported
	c) A lookup that fails will replace the column value with none!


I'm now in the process of benchmarking these changes against sqlite 
to see where the bottlenecks (if any) are. Feedback on the design 
decisions is welcome.


While I was doing this, I was once again reminded how cumbersome 
it is to construct SQL statements (not just for RebDB, same goes 
for the other SQL protocols), as the heavy use of 'compose, 'rejoin, 
etc adds noise that reduces legibility. The design goal is to provide 
alternatives to:


 sql compose/deep [select * from table where [all [col1 = (val1) col2 
 = (val2)]]]


so for a start the 'sql function should probably accept a string, 
to allow:

	sql join “select * from “ table


type constructs; but this doesn't make the first example easier. 
So how about the 'sql function accept a block containing a string 
statement followed by a number of substitution variables, as in:


 sql reduce [“select * from table where [all [col1 = &1 col2 = &2]]” 
 val1 val2]


which makes things a bit more readable (and shortens the expression 
if longer word names are used multiple times). So the two questions 
here are:

	a) Is this a good idea?

 b) If so, what substitution character (& % $ @ other) will cause 
 the least conflict with REBOL and/or SQL?

Traditional with embedded SQL, the technique is to use "host variables" 
which start with a colon:

 sql reduce “select * from table where [all [col1 = :var1 col2 = :var2 
 ]]”
And you'd magically replace :var1 with the value of var1.


Which is almost exactly the behaviour you'd expect from :var1 in 
REBOL too.

If you insist that that host variables always have a space before 
and after, that makes the whole substitution process a fairly simple 
parse operation.

Ashley - why 'replace? Do you want to really replace id with looked-up 
value? I can imagine having some usage for 'id, especially in the 
case where 'id is of some meaning. I know it should not be, but e.g. 
some ppl might use, for companies db, companie's registration number, 
which is not anonymous id, and could be further used in the resultset 
...

wrt simplyfing the use of "noise"  ... why not just call compose/deep 
by default within the 'execute call of the client on ALL sql calls? 
 it could be a global option and IMHO the use of parens within the 
code is quite obvious and is used in many dialects. and its less 
cumbersome than to add the reduce word in your code, a string and 
then variables out of context of the sql statement.

See my post from 12-Feb. The answer to "noise" is substitution variables 
(as it's a form of expression more familiar to long time SQLers). 
Also, I've never liked the idea of performing an operation (be it 
'compose, 'reduce, 'copy, etc) that takes away that choice from the 
coder ... someone may use statements that *never* need to be composed 
and they shouldn't have to carry that cost just because some else 
needs it.

and btw... good job on rebdb... for what it does,  I like it a lot.

is anyone here interested in a contextualised version of rebdb ? 
 I mean one with everything hidden within an object, and most functions 
fixed to support it?

that is not the problem of RebDB imo ... e.g. me and my friend stopped 
using it because of missing 'join and because Ashley stated, that 
instead of reinventing the wheel (RIF based on-disk version), he 
suggests SQLite ....

the only drawback is that sql use needs ticks for table names.   
acter using it for a while I actually like this better, cause it 
clearly identifies what is a reserved word and was is an argument, 
within the statements.

other than that - I like RebDB very much and I regard it being one 
of the best rebol tools so far ....

but you do need to do two queries beforehand... which is not exactly 
a join.. but anyhow you do end up with a block containing interleaved 
data from two tables ... and its pretty quick.

I am trying to update my RebDB database with a level of indirection,
as I am using a block of 39 colunms names and 
the corresponding 39 entry-fields from ReBGui.

Shortening those blocks for the example's sake, I do try to update 
the DB with the following command:

Let's say that exColumns: [name surname dob phone] and exValues: 
["Doe" "Jane" "1990-01-01" "418-840-4040"].

Then >> db-update/where exDB (exColumns) (exValues) compose ['rowid 
= (to-id)] do not work, nor variants I know.
Proof:
>> db-create exDB exColumns == true

>> db-insert exDB ["Foe" "Joe" "1991-01-01" "514-480-8080"] == true
>> db-commit exDB == true

Then what is a working update, as those do not work with indirection 
in column & values spec and rowid?
to-id: 1

Variant1 >> db-update/where exDB exColumns exValues compose [rowid 
= to-id]
== ** User Error: Invalid or duplicate column

Variant2 >> db-update/where exDB (exColumns) (exValues) compose [rowid 
= to-id]

== ** Script Error: db-update expected columns argument of type: 
word block

Variant3 >> do [ db-update/where exDB exColumns exValues compose 
[rowid = to-id] ]
== ** User Error: Invalid or duplicate column

Variant4 >> reduce [ db-update/where exDB exColumns exValues compose 
[rowid = to-id] ]
== ** User Error: Invalid or duplicate column

Variant5 >> reduce [ db-update/where exDB (exColumns) (exValues) 
compose [rowid = to-id] ]

== ** Script Error: db-update expected columns argument of type: 
word block

The more I go, the more I am frustrated into the word/value distinction.
What is the resiliently simple answer to my show stopper?

And about find:
db-select/where * exDB [find name "e"]
Expectedly, any letter of the string searched retrieves it:
>> db-select/where * exDB [find name "e"]
== ["Foe" "Joe" "1991-01-01" "514-480-8080"]
>> db-select/where * exDB [find name "oe"]
== ["Foe" "Joe" "1991-01-01" "514-480-8080"]
>> db-select/where * exDB [find name "Foe"]
== ["Foe" "Joe" "1991-01-01" "514-480-8080"]

But, reverting column and search-string, is this behaviour a specification 
of RebDB, or is it simply luck?
>> db-select/where * exDB [find "e" name]
== []
>> db-select/where * exDB [find "Foe" name]
== ["Foe" "Joe" "1991-01-01" "514-480-8080"]

Following works fine:

	db-update/where names name "Jane" [rowid = 1]

and reversing the find is saying:

	find "e" name -> where name appears in "e" ... so [] is corect

 find "Foe" name -> where name appears in "Foe" ... so ["Foe" ...] 
 is correct

is this behaviour a specification of RebDB

 ... this is how the REBOL find word works. Type "help find" at the 
 REBOL console for more information.

Thanks for the 'find' explanation.  As for the update, the formula 
'db-update/where names name "Jane" [rowid = 1]' is a rather simple 
case.  I am trying to update a 39 columds database splitted into 
3 tab-panels.  So I figure that there is a way to parametrize the 
update and to obtain back, in return, the rowid  where RebDB placed 
it, as the rowid is not allways the same as the saved id, as shown 
in >> db-select id bottinDB
== [1 2 3 4 7 8 9 10]
>> db-select rowid bottinDB
== [1 2 3 4 5 6 7 8].

db-update returns an integer! indicating how many rows where updated. 
Rowid is the physical row sequence computed dynamically at query 
execution.


You can update multiple columns at once by providing a block of column 
names followed by a block of values (but number of values must match 
number of columns). If you are updating a large number of column 
values it is probably more efficient (and easier to code) to delete 
then re-insert the row.

Well.  Is there any way to obtain the rowid (physical row order number) 
of a selected entry, or deleted or updated entry?  I am trying to 
devise a way to navigate into the database, from the initial point 
of a query or of an update.  But with delete operations, the first 
column, id, is not allways in sequence.  >> db-select id bottinDB 
 == [1 2 3 4 7 8 9 10]  >> db-select rowid bottinDB == [1 2 3 4 5 
6 7 8].  And, as much as I can, I want to keep the historical order 
of entry, as it gives me information.  It may be usefull to know 
that I did read a book or meet a person before another. The rowid 
gives a hint to that.  All and all, parametrizing the update and 
obtaining the rowid are stoping me to complete my small everyday 
application.  By the way, I do not see any example of 'demo' applications 
with RebDB and RebGui.  A little help with mine could give birth 
to one.  I should say that, design wise, RebGui is a great decision, 
to favor simplicity.  You adress there some needs never covered by 
other systems: the myriads of simple applets everybody needs but 
were unable to ask.  After a couple of  weekends, I have got 400 
lines of codes and am almost done.  And I am not a programmer. So 
I figure out how efficient it is for you guys. Thanks.

If records aren't inserted often you can use a date/time for the 
field - otherwise use a number that you would increment. Keep in 
mind that if you do a lot of insertions and deletions, a number field 
could end up overflowing unless you occasionally compact the numbers.

Another option is to select the rowid(s) you are after:

	id: db-select/where rowid table [...]

then perform the operations you want:

	db-update/where ... compose [ ... (id) ...]


BTW, thanks for the feedback on both RebDB/RebGUI ... always good 
to know where folks are having both success and problems. More demos/tutorials 
are on the ever growing ToDo list. ;)

hello, i d like to know if its possible to call db.r script from 
an encaped program.  It says that core 2.6 is needed and if i try 
to remove the security it fails.  what i try to do is the following 
:
rebol []


#include %/C/Documents and Settings/xavier/rebApps/spikes/mezz.r;

#include %/C/Documents and Settings/xavier/rebApps/spikes/prot.r

#include %/C/Documents and Settings/xavier/rebApps/spikes/view.r

test: request-file
write %test/param.par test
do to-rebol-file read %test/param.par
probe db-select * patients
ask ""


in this example the file u are supposed to point is db.r.  When it 
s not encaped it work, not when it is.  if someone has an idea ...

A guess is that the path  %test/param.par  is not being resolved 
correctly when encapped. Try adding.
	probe what-dir
and see if the results are different encapped and normally.

RebDB uses features introduced in core 2.6 (case, unless, etc) so 
the solution to your problem is to use an SDK that supports Core 
2.6 and later. Calling %db.r from your encapped script will use the 
SDK version of REBOL, whilst running it from file explorer will use 
whatever version of REBOL is associated with .r files. Latest SDK 
builds are located here: http://www.rebol.net/builds/sdk/


You should then be able to include %db.r directly in your encapped 
script.r.

it works ashley , thanks for everything , u found the solution.  
thanks to that i normally could be able to access to rebdb from my 
encaped program.  I ll do trial to see if i can access to the db.r 
script from the network but normally this could be THE solution to 
my problem.  Thanks for your very good job and for the information 
:)).

Think I've nailed the 3 spots /only is required:

	http://www.dobeash.com/RebDB/RebDB-203.zip


Note that this pre-release includes a few other untested changes; 
including /joins and /replaces refinements to db-select (refer discussion 
from 12-Feb-2006 onwards for explanation).

interesting to know, someone still uses RebDB ... although in-memory 
and not shareable, it is cool Rebol design!

I'm hoping R3 will make it and the SQLite driver redundant ;)

Thanks Ashley!  I kind of got distracted from what I was doing, but 
I'm working on it some more and your fixes work.

Ashley;  Can we get rid of the %rebgui.log  and RebDB %.log database 
replay conflict?  I've taken to just deleting the %rebgui.log on 
app startup, which is probably not a good habit.  Preferred would 
be a rename of the database replay logs to something less 'conflicting', 
say .ldb or some such.  .LOG is too easy to trip over during app 
(especially widget) development.  But I'll accept a nice short No, 
too.  :)

SQLite supports joins, RebDB doesn't.
SQLite driver requires /PRO, RebDB doesn't.
SQLite is disk-based, RebDB is RAM-based.


I use RebDB for small, simple, single-user apps; and SQLite for larger 
multi-user apps.

Ok, I suppose I will have to learn both. RebDB for very simple projects 
and SQL for large ones. After Christmas I will buy Rebol/Pro and 
when my project will be ready the whole suite.

Thought it was about time I started trying some of the great work 
done by the community and stop relying on the slightly less than 
friendly flat-file data storage I've been using.  RebDB is very interesting 
so far.

I think it's a little inconvenient that I can't order by a column 
that I'm not selecting. For example "db-select/order [name] mydb 
lasttime" fails :( Is it possible to work around this, so I don't 
have to select both name and lasttime, because it clutters my code?

If RebDB supported this then it would be no more efficient than doing 
it in your own code (i.e. RebDB would have to retrieve the column 
data required to sort on and then go through another process to discard 
it from the result set). Doing this in your own code is usually rather 
simple, as in:

	foreach [col-i-want col-to-discard] RebDB-query [
		do something with col-i-want
	]

or just using 'extract in simpler cases.

That one got me too.  You don't use /where if you are using a key 
value   db-update database field "Value" 3   will hit the first record 
with key 3.   "key "in this sense means first field in the order 
of the column names.  A block without /where would be implied [value-to-compare-to-first-field 
value-to-compare-to-second-field-value...]  It can be a little weird 
when there are duplicates and you don't use secondary keys to filter. 
There is more to it or course.  But I always use /where syntax.  
:)

The "logic" is that db-update (and db-delete) are logical companions 
to both db-lookup and db-select ... so they have to operate comfortably 
in either mode (key or predicate). It is quite possible to have a 
db that *only* operates in "key" mode and *never* uses predicates! 
;)

I've only used MySQL a little, and quite a while ago, but I _think_ 
update (without where) affected the entire table there. Could be 
wrong though :)


Anyhow, I really love RebDB (And RebGUI also). It's really easy to 
use, and my program would probably be alot messier if I wrote my 
own data management functions :P

You are correct, with a standard SQL DB a delete or update statement 
without a where clause will affect every row in the table. With RebDB 
you can achieve the same thing by providing a where clause as follows:

	where [rowid > 0]


and for delete operations don't overlook the truncate (or drop) functions.

Works great.. Thanks!


You know, a really cool feature for RebDB would be to use tables 
stored on an ftp instead of locally. I think it would be possible 
since it's RAM based and you control your commits, but I could be 
wrong :) Now I'll have to sync my database manually every time I 
change computer

RebDB does have a built in client / server mode if that will help. 
  db-client.r  can talk with SQL.r from just about anywhere.  Or 
try  set path  with an ftp url, it may just work, never tried but 
looking at the code and the use of base-dir it seems like a reasonable 
chance of success.

Is it possible to have some tables locally and some on the ftp? Maybe 
I can make a copy of "db" and use it in parallell?

That will be good enough for me, since I just want to synchronize 
each row in a table every now and then.