World: r3wp

Now, how can all the fields and areas be cleared in preparation for 
entering data for the next record?

Whoops. This should be in the RebGUI group, but I'm going to leave 
it here, since the script needing fixed is here.

Hi, I have a problem wheren using the ? binding feature with integer! 
values. For example:
	["select * from a where mynum  = ?" 1]
won't give an results. But
	["select * from a where mynum = ''1']
gives results.

How is integer! encoded for SQLite?

Does:

	["select * from a where mynum = ?" "1"]

work? If so, then your "integer" is in fact a string.

Another idea could be, that you are somehow mixing "raw" and "managed" 
access, this bit me once, but I think it was related to strings then.

Ashley, no this didn't worked as well. I tried it. That's really 
strange. SQLite browsers see the field as NUMERIC.

What did the statement that originally inserted the value look like? 
What refinement(s) do you use when CONNECTing? Same for both the 
INSERT and SELECT?

I have created a semicolon seperated file and imported it via the 
SQLite command line tool. All numbers where just plain included, 
not guarded by " chars.

CONNECT I just use the CREATE refinement.

I mostly use FLAT for SELECT and no refinement for INSERT.

I send you my version.

Ashley, I notice that sqlite.r value binding is missing some records 
when using LIKE.


>> sql ["select * from base where alamat like ?" "%Grand%"]   <<=====<<< 
This fails.
== "No rows selected."

>> sql ["select * from base where alamat like '%Grand%'"]      <<====<<< 
This finds a record.

It does not always fail, just sometimes. I've not yet discovered 
why.

Ok, it seems to be related to certain records. No matter what word 
I search for it is not found in certain records. So it has something 
to do with those records.

Hi, has anyone even got to the problem, where you import data into 
database, and it is corrupted? (select fails)

I am trying to analyse few sendmail logs. Our admin sent me three 
files. The first one, has those small boxes instead of newlines, 
you know it, when you try to open linux file under windows

I read all thre using read/lines, choose info I want, append it to 
resulting block. Probing block shows no defects. I believe it is 
a REBOL low level bug with some hidden chars. It happened on me in 
the past already, in different situation ...

If I import one file at a time, clear the block, then data is OK 
in sqlite, but if I append first to one block, then insert into sql, 
data is corrupted on few random places ...

following works:

;--- import log files
import-logs: does [

   ;--- pairs of incident No and incident file [[1 filename][2 filename] 
   atd.] ...

   log-files: [[1  06-12-06-7_50-7_59][2  06-12-12-15_46-15_47][3 
    06-12-13-15_29-15_31]]
   foreach file log-files [
     log-info: copy []
     log-file: read/lines file/2  
     ;print length? log-file
     foreach string-line log-file [
       line: parse string-line " "
       if line/7 == "GET" [ 

         append log-info reduce [line/1 line/2 line/4 line/8 line/11 to-string 
         file/1]
       ] 
     ] 

    SQL "BEGIN"

    foreach [date time ip-address url content-type incident-id] log-info 
    [

       SQL reduce ["INSERT INTO logs VALUES (?, ?, ?, ?, ?, ?)" date time 
       ip-address url content-type incident-id]
    ]
    SQL "COMMIT"

   ]
]

If I put SQL section out of the foreach file log-files, simply appending 
all logs at once, data is corrupted ... it is reproducable ....

hmm, it fails too ...

>> do %gotcha!.r
Script: "Untitled" (none)
Script: "SQLite driver" (5-Nov-2006)
>> sql "select * from logs"
** Syntax Error: Invalid string -- "
** Near: (line 1) È&*
6/Dec/06"

here's small package - www.xidys.com/gotcha!.zip

converting the first file (reading and saving) did not help either 
... my suspicion is, there is some bug with driver ...

>> sql "select * from logs"
** Syntax Error: Invalid integer -- 0+*
** Near: (line 1) 0+*
6/Dec/06"

later in the night, or over the weekend I will try not to use block 
syntax, but rather compose query string. All values inserted are 
strings (I tried with native rebol datatypes too)

uf, following works. Maybe it has something with my nonunderstanding 
of differences between string/non string values and how to properly 
insert them ...


 SQL s: rejoin ["INSERT INTO logs VALUES ('" date "', '" time "', 
 '" ip-address "', '" url "', '" content-type "', '" incident-id "')"]

whereas this one does not:


SQL reduce ["INSERT INTO logs VALUES (?, ?, ?, ?, ?, ?)" date time 
ip-address url content-type incident-id]

I am confused about what driver is doing ... the difference of Direct 
mode. Hmm, maybe I do - there is a difference between the string 
mode, and block mode. With string mode, the driver does not touch 
the expression, so I am responsible for putting VALUES('06-Dec-2006') 
or VALUES('"06-Dec-2006"') - simply put - if I want in db to have 
my date value being represented as a REBOL string, I have to put 
it into parenthesis myself. So actually parenthesing it twice, as 
sqlite itself already uses '06-Dec-2006' and considers it being a 
string ...

Maybe there is a bug with block mode?

Does block mode do datatype conversions? Perhaps there is a type 
mismatch.

CONNECT %test.db

SQL "drop table t"
SQL "create table t (c)"

SQL "insert into t values ('Word')"
SQL {insert into t values ('"String"')}
SQL ["insert into t values (?)" 'Word]
SQL ["insert into t values (?)" "String"]

test1: SQL "select * from t"

DISCONNECT

CONNECT/direct %test.db

SQL "drop table t"
SQL "create table t (c)"

SQL "insert into t values ('String')"
SQL ["insert into t values (?)" "String"]

test2: SQL "select * from t"

DISCONNECT

ok, so how can I explain to  mysel data corruption? It is reproducable. 
should I set type of fields when creating tables? Or should I create 
tables in external tool?

Petr, I had the same problem. There is a RAMBO ticket and Ashley 
posted his findings about it.

I use the SQLite command line tool for batch importing.

Pekr, "... Ashley posted his findings about it ...", refer post of 
7th Nov in this group.


Note that it works fine if you use the direct refinement, but then 
you won't have access to the full range of REBOL data types. Also 
note that you can use IMPORT instead of a foreach loop, as in:

	IMPORT statement values

Success! ... of sorts. If you add a 'recycle as the first line of 
the 'sql func then all seems to work fine; but a lot slowwwwwwer 
(1 minute 48 as opposed to 1.5 seconds in Pekr's test case).


But, if you recycle every 100 statements it still works and only 
increases the runtime to 1.85 seconds. I'll do a few more tests before 
uploading a new version with this change.

1.0.2 available at: http://www.dobeash.com/download.html


Workaround to RAMBO#4063. Seems to work with Pekr's and my test cases 
after several thousand runs without error.

Pekr, the import statement for your script would look like:

	sqlite/import "insert into logs values (?,?,?,?,?,?)" log-info


and is about twice as fast as the foreach loop (and now works correctly 
under 1.0.2).

beer-client-loop: func [/local last-mem mem-jetzt ports-bak] [
    recycle/off 
    last-mem: stats 
    forever [
        if error? set/any 'error try [
            wait 0.1
        ] [
            write %autsch.txt mold disarm error 
            win-log 
            print "-----------------" 
            print disarm error
        ] 
        if 20 * 1000 * 1000 + last-mem < mem-jetzt: stats [
            recycle 
            last-mem: stats 

            /print [now/time mem-jetzt - last-mem mem-jetzt last-mem]
        ]
    ]
]

that saved my script, which uses beer and heavy blitting

maybe that methods helps in your case too.

There seems to be a bit messy situation in how integers are handled 
with SQLite, so beware. If you don't specify column types, as eg. 
in my following example:

create table logs (date, time, ipaddr, url, ctype, incident)

, then expect following situation:

1) sql "select incident from logs where incident = 4"   ; works

2) sql ["select incident from logs where incident = ?" 4]  ; works

3) sql "select incident from logs where incident = '4'"   ;  does 
not work


The strange thing is, that editing my db in SQLiteAdmin, it shows 
not column types (but imo it has to choose some "default" type internally). 
Changing according field type to Integer type, makes above case number 
3) to work too ...


So maybe it is always better to not be lazy and specify precisely 
column types? But in fact, when I specified column type as Integer, 
I did NOT expect case 3 to work ... I am going to do more tests myself 
to save myself from later headaches during specifying more complicated 
queries :-)

Be sure to read "Manifest typing" at http://www.sqlite.org/different.html

Petr, yes I have seen some effects of these as well. But didn't tracked 
them further down yet.

I read "manifest typing" and it is strange - even if you set your 
column as an integer, it allows you to enter non-integer data ...

That's cool!! One of SQLite big advantages. Why should I be forced 
to tell the type upfront?

There is just no need for this. The DB should store each cell most 
efficient.

what do you use for typical rebol strings, or even dates? text? varchar?