World: r3wp

I've tested the length? function over port after inserting the port 
and it works well now, is there other bugs in fileports?

Sorry Update on port writes cannot update on port

RebDB question on REBOLforum:

    http://www.rebolforum.com/index.cgi?f=printtopic&topicnumber=46

Maybe it's late and my eyes are not working properly.
I am starting to use REBOLDB for REBOL2.0.

I have read the quickstart guide and now I know how to create a table 
but.. wait: How do I open the table at the next start of my script 
?
I cannot find a DB-OPEN function.

Also, I need to store DATE and TIME together and select rows greater 
than a DATE and TIME value. Does RebolDB support this ?

Any HELP for my problems ? I am stuck with a simple application.

I'm not a rebDB expert....So take my answers as something to be tested:

-- I don't think there is an explicit OPEN command. Simply access 
the table (with SELECT, INSERT, etc) to open it.  Similarly, no CLOSE 
-- use DB-COMMIT to ensure caches are flushed.

--rebDB supports REBOL datatypes. Have you tried creating a table 
row with a datetime in it? Did you have a problem?

Sunanda: you are right. DB il already available without opening it.

Also the function TO-DATE is able to convert from "15 nov 2010/11:30:15" 
to "15-nov-2010/11:30:15" without having to parse the string. Something 
not noticed from REBOL documentation.

(From Ashley on 5-Feb-10:)

All new RebDB v3 released for REBOL3. To take it for a spin, try 
this:

import http://idisk.me.com/dobeash/Public/rebdb.r


when I try this I get an access error - reason: "not found or not 
valid"


Has RebDB v3 moved to a new location ?  Thanks!  Cannot wait to try 
it out.

Ashley: http://idisk.me.com/dobeash/Public/rebdb.rgives this error 
message: Account Error: Missing Data Volume

I've moved from MobileMe to DropBox since then.

import http://dl.dropbox.com/u/8269768/rebsm.r
help db-
test: db-load http://dl.dropbox.com/u/8269768/test.bin
help test
sql select test


I'm in the process of rebuilding my Dobeash site and will be adding 
this (and a few other goodies) along with documentation when done. 
No ETA, but it can live on dropbox until then.

thx, Ashley

what is the advised server / client setup? where should be the source, 
the data directory and the login.sql files for the server and the 
client?

and the spool file... which is suggested to be called session.log 
but then it will be replayed by the commit * in login.sql if it's 
in the data directory..

if exists? login: join system/script/parent/path %login.sql [ client/run 
login ]

this would make more sense to me in SQL.r, so any directory with 
a login.sql could be either a server or client directory

it would also make more sense to call it init.sql and provide a client.sql 
and a server.sql as examples in the distribution

if im enabling the spool feature, i just get this error:

onetom ~/rebol/db $ rebdb
Replaying 9 change(s).
** Script Error: Out of range or past end
** Where: func [/local log][
...

the only way to restart the server is to

onetom ~/rebol/db $ rm ../rebdb/replay.bak ../rebdb/session.log

if i do a commit *, then the replay.bak won't exist, but the server 
will still try to execute the session.log, which results in fractional 
changes:

onetom ~/rebol/db $ rebdb
Replaying 4.5 change(s).
** Script Error: Out of range or past end

if i say set spool session.txt, then it works.. pretty confusing 
default. and i would expect the file created in the current directory, 
not where the db.r file is stored

and now i get

SQL> select * asd
asd has an open log file

commit asd doesn't help

Is there a protocol version of RedDB ? In order to use it under Cheyenne 
with database enhancement.

No, but it wouldn't be that hard to write a protocol wrapper replacement 
for the SQL function.

Cheyenne is able to run RSP and CGI scripts concurrently on several 
processes at the same time. AFAIK, RebDB does not do any locking 
on write access, it would be unsafe to use in the general case with 
Cheyenne. SQLite would be more resilient, but keep in mind that as 
it is locking the whole DB on each write access, it is not scalable.

The new(er) WAL (Write Ahead Logging) transaction mode reduces locking 
and increases concurrency -- http://sqlite.org/wal.html.

Seems that the SQL interpreter (SQL.r) do not support multi lines 
:

SQL> create table c2 [
** Syntax Error: Missing ] at end-of-script
** Near: (line 1) create table c2 [

Correct, it's just an 'ask loop (hence no semi-colon for command 
termination).