World: r3wp

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.

Correct,

	db/base-dir: ftp://user:[pwd-:-ftp-:-site-:-com]/public_html/
	db/lines?: false


The second line will help minimize the amount of traffic by turning 
line breaks off.

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?

Table location is a global setting, so no. You can run two copies 
of %db.r (with different base-dir settings), but they won't share 
the same memory space.

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

This ftp based storage is kind of neat.  I have to update my users' 
tables, and need to provide a script that updates their firebird 
tables.  I can embed the data in the update script, but this sounds 
a much better idea.

Ashley are you planning to release 2.0.3 as a production version?

I find that the db/base-dir is getting set to the directory from 
which the db.r is loaded.  Is this behaviour intentional?

>> what-dir

== %/Users/peter/Desktop/RebDBTest
/
>> do %~/Code/Library/Rebol/RebDB-202/db.r

Script: "RebDB server" (14-Jan-2006
)
== none

>> what-di
r
== %/Users/peter/Desktop/RebDBTest
/
>> db/base-di
r
== %/Users/peter/Code/Library/Rebol/RebDB-202/

Sorry about the formatting..as you might guess I'm running AltME 
on a Mac.

Same here ... and yes that behaviour is intentional. 2.0.3 is stable, 
it just requires some doc updates. I'll see about releasing it in 
a day or two.

Thanks no rush on my part.

2.0.3 released. Release notes can be found here:

	http://www.dobeash.com/RebDB/release-notes.html

Ashley, which is easiest to use with RebGUI? RebDB or your sqlite.r? 
 Also, how do you decide which one you will use for a particular 
project?

Depends on how much data and how much complexity you need. RebDB 
is good for under a million rows where the column data is short (i.e. 
not storing 1MB strings). SQLite is a better choice for lots/big 
rows or where you need non-trivial joins/views. I'd use RebDB for 
simple apps like a "Contacts" DB, and SQLite for anything requiring 
half a dozen or more tables.

Ok, thanks. That make the choice easier.

Whoa.  2.0.3; that was a pleasant surprise.  Thanks Ashley.

hi,  how a can do a select with "like "     =>  select * from table 
 where name like 'RA%'

I think the find clause here might work for you: http://www.dobeash.com/RebDB/sql-guide.html#section-4

Don't expect it to be fast though.

thank you very much BrianH

Ah, I just noticed all the "(br)" entries ... that'll teach me for 
changing make-doc versions! ;)

Fixed.

Is RebDB disk based or is the enitre DB loaded into memory?

Entire DB is loaded in memory. If that is a problem, use SQLite.

How much is involced in using sqLite? And how large is it?

225K..small enough

The REBOL driver is a little smaller than RebDB, but there is a dll 
that is about 200k. The databases are smaller, I think. Look in the 
SQLite group here for details.

. .

Ashley - how do I overcome this problem:  I need to reduce the record 
block prior to db-inserting it because it contains sub-blocks. I 
would like to use 'next inside for autoincs, however.....

hi ashley, i would like to know if you  would port rebdb to R3 ?

Kai: use "reduce ['next ...]
Claude: I will, but only when R3 goes Beta.

Latest version of RebDB appears to work under R3 with only 2 minor 
changes:

	1) Change the Umlaut u on line 3 to a normal u
	2) Change the 'return on line 214 to 'exit


Once I've had some time to run a few QA tests I'll upload these changes 
as 2.0.4 (along with a few other maintenance fixes).

cool

The other big news is that I've commenced an R3 specific rewrite 
of RebDB focusing more on the Storage Manager (as opposed to the 
Database Manager). Preliminary results, pre-optimization, look very 
promising:

Script: "RebDB server" Version: 2.0.3 Date: 13-Apr-2007
Rows ...... 10,000 * 2
RAM Used .. 1,225 Kb
Insert .... 0:00:05.02291
RAM Used .. 6,497 Kb
Delete1 ... 0:00:42.43421
RAM Used .. 5,346 Kb
Delete2 ... 0:01:13.110128
RAM Used .. 6,100 Kb

Script: "RebDB Storage Manager" Version: 3.0.0 Date: 1-Feb-2010
Rows ...... 10,000 * 2
RAM Used .. 1,029 Kb
Insert .... 0:00:00.689558
RAM Used .. 4,568 Kb
Delete1 ... 0:00:05.103824
RAM Used .. 1,991 Kb
Delete2 ... 0:13:47.026307
RAM Used .. 1,991 Kb


Delete1 is primary key-based (10,000 deletes), whilst Delete2 is 
query-based. Apart from the sluggish query performance, what's noticeable 
is the more efficient use of memory. I've opted for a mixed binary! 
storage design where fixed-width fields are stored in RAM in a single 
binary! with pointers into a disk binary. The idea is that you'll 
generally want fixed width records in memory to query against, with 
variable length records (BLOBs) accessed on disk less frequently 
(e.g. specific text/binary attachments).


All this is then wrapped up into an object so creating a table is 
as easy as:

	test1: db-create [integer! 8 string! 12 string! 15]


with all other commands (db-insert, db-update, db-delete, etc) working 
as under v2. Oh, I've also cut the code size from 1,300 lines to 
less than 400 (75% complete). The final goal is to deliver what RIF 
promised ... a simple storage mechanism that provides the basic building 
blocks required by higher-level database systems (akin to ISAM or 
VSAM files).

does it do joins? :-)

but honestly, Ashley ... absolutly great work. I was using RebDB 
initially, untill I needed few joins, and found out beauty of SQLite.

sounds great

great news !!!!

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

import http://idisk.me.com/dobeash/Public/rebdb.r
help db-
test: db-load http://idisk.me.com/dobeash/Public/test.bin
help test
sql select test


Extensive documentation in the works (within a week) ... actually 
a large part of the doc deals with db design [from my POV] covering 
off on the trade-offs with fixed vs variable length records/fields, 
typed vs untyped columns and RAM vs speed optimization. Needless 
to say, I think I've got the balance about as good as is possible 
with pure REBOL mezz code. This has been a long time in the making 
...

Cool! You can repost in Announce group .... and it could go into 
rebolweek too :-)

What's the final code size?

Is it still pure ram based?

amacleod - I would expect it being only RAM based. However - even 
old version contained transaction log, so that in the case of power-loss, 
it automatically rolled all the changes in.

>> length? read/binary http://idisk.me.com/dobeash/Public/rebdb.r
connecting to: idisk.me.com
== 12771

... so it's already mid-sized REBOL app :-)

I was wondering in terms of number of lines as he mentioned above...compared 
to r2 version...

Still under 500 lines in my editor

A testament to R3 code?

With cloud tech so big now a cool product for rebol would be some 
kind of server/client DB with built in syncronization methods. I 
do not know if RebDB can be adapted to fit that bill...

this is very cool.. I hope I will be able to study a little what 
you did.. I was lately playing with creating a simple data storage. 
To learn more about things and because sqlite has some bad sides 
, and mysql is not appropriate for my particular usecase.