AltME: Databases


After some time, I gave a try to the Sqlite DB. It kind of improved in some areas, even locking, so it is even more useable in concurrent environment. However - it still uses per file lock, and although it uses just milliseconds to lock the file, I have a problem with one aproach I am trying to take, and hence maybe the Sqlite is not right DB for my purpose, or my aproach is not correct. The reason why I wanted to use sqlite DB is, that it is easily movable to other target, and its performance is fine for even semi heavy solutions. I don't want to be dependant upon the some kind of "server", which stores its files who knows where, and to which I don't have proper access in cgi environment, unless I am a DB admin or server admin ...
Simply put - millisecond lock time is enough fine grained for my purposes, but - let's assume you have several ppl working on some customer list, where each customer has some orders. Those ppl do select particular customer, and work with orders. What I want is - when some user selects particular customer, I need its record being locked. The trouble is, that when I use BEGIN transaction for sqlite, it locks all the file, and does not allow other process to do write to the DB.
I wonder, if I can somehow obey it, not really having per record locking. I would have to implement my own lock mechanism (not locking in fact), not allowing others select/enter customer record, when some other person is working on it?
Or simply I have to use more powerfull SQL solution, but heck, I don't like all the heave SQL servers for some simple few tables solution ....

It's interesting when I try to connect using a port scheme I cannot get error msg:
>> con: open [scheme: 'odbc target: "..."] ;try with wrong password for example
** Script Error: ODBC error:
>> con: open odbc://sa:qwe1234@mydsn
** Script Error: ODBC error: [Microsoft][SQL Server Native Client 10.0][SQL Server]Login failed for user 'sa'.  <<< now I got error msg.
Any idea how to get "real" error message?

Shouldn't that rather be HOST instead of TARGET?
>> con: [scheme: 'odbc host: "mydsn"]
Only if the target is a DSN with no other settings specified. Otherwise, use target.
con: [scheme: 'odbc target: "dsn=mydsn"]
For instance, this is a common connection I use at work (server name changed):
conn: [scheme: 'odbc target: "driver=SQL Server Native Client 10.0;server=SERVER1;database=db1;Trusted_Connection=Yes;"]

I've just updated the R3 ODBC Extension to work with more SQL types and, with the support of BrianH, fixed and improved the boot code OPEN and COPY actors.
The extension is available over at Github in both source form as well as a DLL compiled for windows, see

dll compiled means use from R2?
It's an R3 extension. You could load it in R2, but you'd have to program the interface to the extension yourself

Is anyone using Doc's MySql protocol (v4.1 1.3.0) with MySql 5.5.24-cll, protocol v10?
I have a client migrating to a new host. We've been using 1.2.1 against mysql 5.0.95, but 5.5 triggers the client auth error. Moving to Doc's 4.1 version solved that, but a simple test query returns an empty block.
Can't rule out a data migration error yet, as things just moved and getting connected was the frist step. Just curious if someone is known to have this combo working.
Nevermind. I was able to test another query which works, so all is well there. Thanks Doc, once again!
The failing query was a data migration issue, just FYI.
I just upgraded local ubutu and I made the rebol work with ia32-libs again, now rebol mysql client is givin me auth error
Gregg: what did you say you did to make it work? what did you move to 4.1 the mysql server or something else?
Janko: if you're using a newer MySQL version, you need my 4.1 driver.
aha, I hoped he meant that :) , but I only found 1.2.1 on your website
I am looking at this page (google doesn't find me any ohter, I think)
It's not an official release yet...I wish I had time to finish it...:-/
IIRC, it was missing some minor feature support from the protocol and good new test cases...

Last message posted 143 weeks ago.