World: r3wp

Or, do I edit cheyenne.r to do that?

Right, using 'do-SQL makes Cheyenne manage the connection for you. 
You need to define your DB connections specs in the httpd.cfg file, 
like this for example :

databases [
		bugs	mysql://[root-:-localhost]/bugs
		forum	mysql://root:[admin-:-localhost]/forum
		test	mysql://[root-:-localhost]/test
	]

then, if you're not using RT's DB drivers, you need to load your 
driver somewhere : %misc/rsp-init.r or %www/your-app/app-init.r (if 
you've defined a webapp) are good places to do so.

this is a lot more complicated than the 2005 version :)

so, to send a query to "bugs" ?

DO-SQL syntax : do-sql [db [word!] data [string! block! word!] /flat]

The RSP engine will do all the opening/closing work for you

why do you want to close the db connection?

Can't you leave it open all the time?

re 2005 version: you're don't need to use do-sql if you don't want 
to. You can do it as usual by opening connection, sending query...closing 
connection. do-sql is just a higher level wrapper to save you some 
time.

do-sql [ bugs {select * from database} ]   ?

before I just opened the odbc connection when cheyenne started and 
just kept reusing the connection

the DB connection is done from one of the bg helper process, so if 
the process quits, it should close the DB connection properly.

I c

nope, I've just copy/paste the do-sql func spec block, sorry for 
being confusing.

do-sql 'bugs "select * from database"

do-sql leaves the DB connection opened until the process quits.

ahh....

and there's a query object that holds the result of the do-sql ?

I'm looking at the rsp-api.html and don't see anything there

The "Global Functions" and DB-object cache are not yet documented.

'do-sql returns the resulting recordset

DB-object cache => DB-cache

the current rsp-api doc is just an API reference documentation, I'll 
provide a more general explanation about RSP concepts and features 
separately in a few days.

Ok. Thanks

Does Cheyenne honor the shebang on rebol cgi scripts ?

It just skip it.

Or, does it just spawn a separate rebol process for it?

Ok, I presumed it wasn't necessary

Cheyenne uses one of the bg process to execute the CGI.

That way Cheyenne achieve FastCGI speed on normal CGI scripts.

Before I think I checked on each page to see if the user was authenticated 
by checking the session.  But it looks like this is now automatic, 
and the user is sent to login page if they access a page and the 
user is not authenticated?

Right, but only if you're inside a web-app container (defined in 
the config file). Otherwise, it's up to you to do the checking.

You can use RSP at 3 different levels :

1- raw RSP pages : no session data

2- RSP with session context : start a session using SESSION/START 
and keep some data persistant in the session context.

3 - Web-app : RSP application container, automatic session management, 
login state built-in support, etc...

well, that makes it easier :)

## Error in [conf-parser] : Error in conf file at:
remr odbc://remr !

Hmm.  Doesn't like my database block.

databases [
		remr odbc://remr
]

the databases block have to be in : globals [...] specification block

Ok, now working there.

Should this work?


	in-user: select request/content 'login
	in-pass: select request/content 'pass
	
	if all [ in-user in-pass ][

  result: do-sql 'remr rejoin [ {select staffname from staff where 
  staffname = '} in-user {' and pwd = '} in-pass {'} ]

		print <pre>
		probe result
		print </pre>	
	]

Error Code :  	305
Description : 	script error !

Invalid argument: select staffname from staff where staffname = 'test' 
and pwd = 'letmein'
Near : 	[any [
insert pos/2 data 
copy pos/2
]]
Where : 	do-sql

if you're using the odbc:// driver, like all RT's DB drivers, it 
requires a : first db-port to open the connection port, so you have 
to change the do-sql source a little bit (in %handler/RSP.r file), 
in do-sql source :

if any [block? pos/2 url? pos/2][
	poke pos 2 open pos/2
]

replace it by :

if any [block? pos/2 url? pos/2][
	poke pos 2 first open pos/2
]

I'll fix that for next release. It wasn't a priority for me until 
now, because I only use my own DB drivers which API differs a little 
from RT's ones.

Ok.