World: r3wp

You have to try. The SQLite driver uses a heuristic every 100 rounds 
or so. Just play around to see if it makes a difference.

That's one cause why I want to get my hands on the external library 
interface in R3 ASAP.

Thanks Robert.

Robert - what is your preferable method for "DLL interface"? Is it 
a mixture of rebol dialect (as in R2) and plug-in aproach?

I don't know anything about the plug-in approach at the moment, so 
I can't say.

Overall I don't care to much, which way we go. It must be simple 
and straight forward to use. And we must have a way on the Rebol 
side to privode the C side of life. Like pointers and structs etc. 
without tricks.

Robert, 'recycle' worked like a charm!
Thanks a lot.

I had the same problem when reading from the DB so I used 'recycle 
again in hte query loop....

This had the added benifit of of sealing amemory leak with the images 
too.

Memory would increase evrytime a new image was displayed but now 
it tops out at an acceptable level..

Is this GC problem being worked on for 2.7.7 ??

Right now 2.7.7 is not being worked on at all. That sonds like a 
good thing to fix when we do start working on 2.7.7.

I like  2.7.6 is the last of the 2.x series.  Brian may release a 
library containing updated mezzanines and patches.

like = think

We find new bugs in R2 natives all of the time - Carl just found 
one in the last week. There will likely be bugfix releases, but no 
incompatible changes will be made to R2 anymore, afaict. All of the 
new functions in R3 and incompatible improvements to existing functions 
will likely be made in a separate script that you can load or encap. 
That script will be maintained outside of the R2 update cycle. I 
think that will be the plan, at least.

There may be some changes to behavior that was so broken that it 
couldn't possibly have been relied on by existing code, like the 
change in return value of ALTER in 2.7.6. I would be surprised if 
the INSERT/dup/part bug Carl found this week isn't fixed in the next 
R2 release, for instance, whenever that release happens.

I think it will be a long time before R3 is usable in the real world 
... so my understanding is that there will still be 2.7 releases.

I agree. None are planned at the moment, but it is likely that there 
will be more in the future.

I can't seem to find info if dobedash's sqlite.r should work with 
sqlite3.dll or sqlite.dll, does anyone have any idea?

IIRC it supports version 3 of the driver. Dunno the name of .dll. 
But - just rename sqlite3.dll to sqlite.dll and run few tests, no? 
:-)

It worked for me but now I started to get "Not a database or encripted" 
error and I couldn't figure out why.. I discovered that the sqliteadmin 
app was making v2 files now and that was the problem.

a view into db file as hex quickly resolved which version is which, 
it is written at the start, and so I saw what is going on, thanks 
Petr

.

Did anyone try using sqlite.r from Dobeash in free rebol code 2.7.6 
on linux. (debian). I get "feature not available in this REBOL" but 
it works on windows.

I think the library calls are not enabled in linux version of Core.. 
ask Carl.

Or you can use Rebpro from Rebol's SDK

Oldes: yes, it looks that way by the error given

I am an new/old user so I am still on free versions of rebol.. I 
gues now is time to buy the SDK

I think you don't need the license

just download it and try it

http://www.rebol.net/builds/#section-1

At least what I was trying, there was the license message on boot, 
but I could use the /library

hu, I never saw that download page :)

wow.. first rebol download > 1MB :)

aha.. I am getting somewhere .. it alows it now but I get some error 
with .so .. maybe this is the reason cheyenne can't open it either 

>> do %sqlite.r
Script: "SQLite driver" (26-Nov-2008)
REBOL - Security Check:

Script requests permission to open a port for read/write on: libsqlite3.so
Yes, allow all, no, or quit? (Y/A/N/Q) Y
** Access Error: Cannot open sqlite3_prepare_v2

** Near: *prepare: make routine! [db [integer!] dbq [string!] len 
[integer!] stmt [struct! [[integer!]]] dummy [struct! [[integer..

you have to start it with the -s switch and good is to use the -q 
switch as well.

http://www.rebol.com/docs/words/wusage.html

-s probably means without asking for permissions... I tried now rebpro 
-s -q but I got the same .so error .. maybe I didn't prepare the 
.so files well ..I am just looking into docs

>> do %sqlite.r
** Access Error: Cannot open sqlite3_prepare_v2

** Near: *prepare: make routine! [db [integer!] dbq [string!] len 
[integer!] stmt [struct! [[integer!]]] dummy [struct! [[integer...

when I installed sqlite with apt-get install sqlite3 I got 2 files 
into /usr/lib/ directory   ./usr/lib/libsqlite3.so.0.8.6  and   ./usr/lib/libsqlite3.so.0 
... if I run rebol it doesn't find sqlite so I copied one of them 
(I tried with both, they are of same size btw) to directory where 
rebol / rebpro and sqlite.r is and renamed it to    libsqlite3.so 
  and then it seems to find it ... now this is just common sense 
as I am not that experienced with this on linux

ah... I looked at history of this chat and saw that there is debian 
package libsqlite3-dev ... I installed this and now I have libsqlite3.so 
.. it seems rebpro finds it without copying it to local directory 
now but it still gibes the same " Cannot open sqlite3_prepare_v2" 
error

ha.. I changed sqlite_prepare_v2 to sqlite_prepare in sqlite.r and 
now rebpro and cheyenne work!!

I hope this doesn't mean I something else won't work as it should

Have your application execute the following SQL statement and then 
look at the result : select sqlite_version(); 

AFAICT, sqlite3_prepare_v2 is available starting from SQLite 3.5.2.

aha.. stupid me.. apt-get usually doesn't provide latest versions 
but a more "stable" ones ... yes it's  3.3.8

You don't need to use apt-get for sqlite, just download the latest 
library and put it in your app folder near sqlite.r : http://www.sqlite.org/sqlite-3.6.11.so.gz
(I guess you'll need to rename it to libsqlite3.so).

thanks Doc!

I did not realize sqlite.r was set up to use mysql3.so (linux libs) 
Got my app running on linux witout a hitch...
Auto detects OS...great!

this might be usefull to users of sqlite.. I yesterday encountered 
the "db is locked" error and it got me a little worried, but with 
this (simple) aproach it seems to solve that http://itsystementwicklung.de/pipermail/list-pysqlite/2009-April/000380.html

.

I don't get this ... I started getting very long loading times with 
my webapp when I changed or inserted the and it was very fast before 
... now I saw that it's the sqlite making these delays.. this is 
not the problem of sqlite.r but the sqlite itself because I get the 
same behaviour with sqlite3 shell.


But I can't believe this , I am certain I am doing something wrong.. 
I remember sqlite can handle GB of data and is very fast, but in 
my case... I have 183 rows in a simple 5 column table (db file is 
10kb) .. if I do single update table X set y = ".." where Z = ".."; 
 it takes like 3 seconds. This updates just 1 row out of 183. Does 
anyone have any idea? I tried to do the "Vacuum" command but it's 
the same after it.

can you post whole query?

I also added the indexes now and it is maybe a little faster but 
on single where but on both that I need it looks more or less the 
same (select by same condition is imeddiate)

Pekr.. I will