World: r3wp

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.

It sounds like you should add your own field for insert order. I 
don't think that RebDB keeps the records in the order it inserts 
them. Even its web site says that it sorts the records when selecting 
- this isn't Access you know. If you want to keep some information 
in the database, put it there.

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. ;)

Thanks for those suggestions.   If I finish it, I'll feedback with 
it.

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 
:)).

Ashley, I noticed some strange behavior with db-select.  If you do 
NOT supply the /where argument then blocks are inserted into the 
result correctly but if do they are inserted inline.

Example:
>> db-describe tags
== [id integer! tag string! files block!]
>> db-select [id files] tags
== [1 [3]]
>> db-select/where [id files] tags [tag = "t"]
== [1 3]


I've spent about an hour trying to find where to fix this in db.r 
but I'm not seeing it.  Any ideas?

Sounds like a missing /only refinement on an insert. I'll look at 
this later tonight ... odd how no-one else has hit this in over 2 
years ... maybe not many folks store blocks! ;)

That's what I thought so I started poking around but I didn't find 
the place to add the /only to...

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 ;)

ah, high hopes :-)

I can imagine solving even sharing problem - simply to queue requests 
....

the question is, if RIF comes or not.

what about locking?

locking? why not? You can distribute ticket :-)

there is the concept called, uh, I forgot, java persistent database, 
few hundred of lines of code ....

Maybe an interesting project? http://sqlrelay.sourceforge.net/

Looks interesting. I will see how this works with SQLite & RebService...

Pekr, you're thinking about "Prevalence" ? http://www.advogato.org/article/398.html

Doc, yes, it was Prevailer ...

Prevayler

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.  :)

db/base-dir: %data/

Thank you sir.  That's a way round.  :)

Hello, I have a question: which are the advantages of SQLLite over 
RebDB ? I have to chose something to lear for my projects.

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.

Ashley, what I am doing wrong here? (I'm trying to sum the column 
"distance" below):

SQL> select distance my-table
distance
--------
1
3
7

SQL> select count distance my-table
Count
-----
    3

SQL> select sum distance my-table
script cannot-use

One or more of your values is a string. Check the contents of my-table.dat

Of course. I  need to drink more coffee. Thanks, Ashley.

Ashley, just noticed the RebDB on your Dobeash website is not the 
latest version.

Check my message above from 13-Apr-2007 ;)

Gotcha, thanks.   That's actually where I go the link, just didn't 
read far enough to see that it was pre-release.

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.

no problems.. didn't know about extract so now I'm using that in 
conjunction with random/only :)

I don't think I understand the purpose of "predicate" in db-update, 
where you don't wan't to use /where..

ie anyone wanna explain? :)

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.  
:)

thanks alot mate!

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.