World: r3wp

For the lonlong conversion, the conversion model is initialized to 
none. It should be initialized to integer like this :
	conv-model: [
		decimal			[to decimal!]
		tiny			[to integer!]
		short			[to integer!]
		long			[to integer!]
		float			[to decimal!]
		double			none
		null			none
		timestamp		none
;		longlong		none		; Removed
		longlong		[to integer!]	; Added
		int24			[to integer!]
		date			[to date!]
		time			[to time!]
		datetime		[to date!]
		year			[to integer!]
		newdate			none
		enum			none
		set				none
		tiny-blob		none
		medium-blob		none
		long-blob		none
		blob			none
		var-string		none
		string			none
	]

And the last bug is that the "byte" word is not initialized to none 
and this cause a problem but I don't remember the effect :
;------ Data reading ------


;	b0: b1: b2: b3: int: int24: long: string: field: len: none	; Removed

 b0: b1: b2: b3: int: int24: long: byte: string: field: len: none	; 
 Added

nice - so, let's wait what Doc thinks about it ....

the truth is, that I met with no problem so far using current scheme 
....

but as I said - I am not sure, if ?query-here should work for other 
than 'read attempt .... 'open should imo only be provided with url 
plus target db, not query itself ...

I sent the bug and the correction to Doc some (many) month ago.

Here is the exact bug caused by the initi function (the bug was already 
found in november 2003)
>> db: open mysql://narg:?@host/bicycle
** Access Error: Cannot connect to narg
** Where: open-proto
** Near: db: open mysql://narg:?@host/bicycle

Fix #1 : Byte word added to local context.

Longlong conversion: I don't agree with you. The server returns a 
64-bits integer that you're casting to 32-bits integer, so your losing 
half of the data. Btw, even casting it to decimal! which is 64-bits 
wide won't be accurate because of the integer to floating point conversion 
issues. That's why I've left it to none (means keep it in raw string! 
format) and let each user decide how to process it. (The driver provides 
the 'change-type-handler global function to change that easily)

Fix #2 : port init now correctly handle '?' marker. I've used your 
patch as is. Works well with all my tests. Thanks for providing the 
fix for this long standing bug.

If anyone has some other patches, let publish it here. I'll wait 
a few more days before closing the beta state and declaring this 
version the new stable one.

New version 1.0.1 including these fixes available (http://softinnov.org/tmp/mysql-protocol.r).

Doc, what would be needed for the driver to work like Command driver? 
I mean the ability to db-conn: first db, and have multiple connections/channels 
to have available?

You already can have several connections opened at the same time 
with the current driver. I don't see the benefits of the /Command 
way. If you really need to have exactly the same behaviour, I guess 
that you have to overload the 'first function in my code and return 
a new port! using  the connection port  as 'sub-port.

Actually, I used to install Docs driver in Command anyway because 
it was much faster :-)

yep, our detective portals use Doc's driver even though we run on 
command.

Guys, I keep been amazed how libmysql using C poorly performs against 
a direct TCP approach using REBOL.

I have plans for a version 2 of this driver including a full code 
rewritting for much cleaner design, speed improvements, optional 
async API, support more protocol features (like LOAD DATA), implement 
the v5 protocol, improved user API (e.g.: select column in a record 
by field name), etc...

Exists a "standalone" mysql version? Or a standalone database that 
is mysql compatible?

What do you mean by standalone ?

So, no big installation. Like a DLL or  just an EXE that's started.

there is an embeddable version of mysql as a dll

but it is gpl afaik

There is this apache + x which Terry likes. IIRC mysql is included 
too?

well using a DLL won't make the rest GPL.

so you need to contact mysql ab for use in non-gpl apps

What's appache + x?

some bundle for lamp on windows.

it does, if yor programs depends on the dll (doesn't work without) 
though this is debatable (not proven in court i guess)

So I wouldn't care.

http://www.apachefriends.org/en/xampp.html, from framewerks-group

but if you just need an sql engine... why not sqlite?

I need one that's integrated into Rebol. Didn't took a look at it. 
Just thought it makes sense to have a protocol like DocKimbel's and 
re-use it with different databases (R-ODBC)

sqlite is specially to run as DLL afaik.

Robert - you might be better looking somewhere else. Mysql embedded 
does not have tcp/ip api, just some library aproach ...

what about sqlite or rebdb? RebDB should be ok for most your projects 
imo ... (although 'join is badly missing)

Robert - french community did some work for sqlite iirc ... look 
at rebol.org ....

Doc - you once told me that your postgress driver is some xy percent 
faster, because of continuous parsing or so, maybe you could rewrite 
mysql to use similar principles?

Pekr: I'll use that method for the v2 of the driver. It also helps 
keep the code more elegant.

but mysql protocol is not your priority, is it? It simply works now 
:-)

Uniserve 1.0, or R# would be nice though :-)

My current priorities are project generating incomes. Unfortunately, 
I have very little time for other projects.

Uniserve is one of our base framework  (both for internal use and 
for our customers), so we're working on it actively.

I'll release it as soon as I find some time to update the docs and 
package it.

Doc,  I'm not sure if you've got this yet or not,  but we found a 
bug where the 'read-packet function's buffer was not getting expanded 
properly which was causing it to truncate some of our data.  To fix 
this problem then we added a local variable and added these lines:

tmp: pl/cache
pl/cache: make binary! pl/buf-size
system/words/insert tail pl/cache tmp

after this line:

pl/buffer: make binary! pl/buf-size: packet-len

Hi Ammon, it is possible that there's some issue maintainin the 2 
buffers size in sync. I've added your patch (with small modifications) 
to the current code.

v1.0.2 including Ammon patch uploaded.

Thanks!

the "Bad handshake" issue appears randomly when logging to the server. 
It looks like it's related to the server side.

Ok, I've found a workaround for this problem. I still have a 1045 
User deny random error to fix (almost done) and make a new release 
tomorrow. 1.0 official release is now very close.