World: r3wp

can someone tell me if they are also getting erratic behavior from 
the (EXCELLENT!) mySql Client from DocKimbel ?

I have been doing selects and have about 1% failure rate...

it gives me an access denied error, from the mysql server, yet I 
am right in the midst of a heavy bunch of requests...

we are using v4 of mySql ...

I was thinking there might be a timeout value which is set a little 
too short, but I am such a neophyte when it comes to tweaking ports 
and with mySql in general...

I was having the exact same problem the other day.

did you find a solution?

I tried a manual "wait" between requests, but would still choke.

no

Or actually yeah.. I'm going flat file ;)

he he...

Look at my conversation in the All group.. late Saturday night.. 
early sunday morning

hum, I am calling  wait  0.01  pretty often within the script to 
allow the asynchronous rebol core some breathing time which REALLY 
rocks btw... scanning multiple dirs, while letting the UI and mySql 
to work at the same time , I'd not be able to get it running so easily 
in any other language.... :-)

I've also noticed some "access error" messages from the server under 
heavy loads. A possible solution is to make connections persistent 
to avoid the open/close overhead for each request. This should solve 
most of these kind of issues.

Sadly, it's not usable for CGI :-(

CGI are slow, I'm not sure that you can easily overload a MySQL server 
that way. Did anyone experienced such issues (access deny errors) 
from CGI ?

there's some 1% of failures for me to. so far, it hasn't been a great 
problem. but, surely it would be great to be able to solve this issue.

doc: to me it happens with completely unloaded server too

i just have a retry button in my apps so that's not a problem - but 
sometimes you need to press it.

on cgi this is more annoying; it happened a couple times on the detective 
builder web interface too.

Off topic question. Is there a way to access the result block of 
query using the field names? Kind of an object for the cursor?

Ok, I'll give it a deeper look when I'll release the next version.

I have Cheyenne and UniServe releases pending in the pipe, mysql:// 
update is next on my list.

Jaime: i have functions to do that, you'll find them in the mysql-wrapper.r 
script that comes with mysql-protocol.r

Like Gabriele, I have sometimes error with CGI connecting MySql but 
the server seems to not be loaded.

Thanks Gabriele.

Didec, does it happen with a single connection attempt or when you 
retry several times (sending lot of connection requests to the server 
in a small delay) ?

in my case, single connection attempt.

Interesting. Thanks Gab.

I think so. I should add that I have no problem on my Win2k3 server, 
but only on the Linux ISP host !!

But the Win server and the client are on the LAN 100Mbits

so, as long as you have an open connection, there is no problem?

Right, the problem is to get connected to the server. Sometimes, 
the server reject the connection attempt. If you successfully connect 
and keep the connection opened, there should be no problem AFAIK.

Good.  I think was thinking of porting my portal server over from 
odbc to mysql://

Got a problem where the server app while in a wait state jumps to 
50% cpu, and memory jumps from 4Mb to 30Mb .. using rugby.

On a persistent connection I had only problems when firing requests 
from a scroller driven list. A simple construction to prevent  concurrent 
requests solved the problem:

if not dbBusy [
	dbBusy: true
	mydata: db-read-page fields table start pgLen 
	show mylist
	dbBusy: false
	]

Rolf: is your db-read-page function using WAIT?

but, this poses an interesting problem with the new async core...

Gabriele, I do exactly the same kind of work arounds, in my apps, 
I just highlight the panes which have failed and include a user-driven 
"refresh button"  but this is not very elegent.. nor is requerying 
until no error is returned...  although I was thinking of adding 
a persistent requery in my  top-level query function.

The server I am accessing is very quick and in general, it accomplishes 
its query in micro seconds.  so its not really a question of server 
load...

Doc.   my very competent db admin, told me that it could simply be 
an issue that the client is expecting a reply from the sql server 
too quickly and that it is likely a simple timeout issue.  HTH.  
 if there is a way to let the tcp wait a bit more, it could be that 
the fraction of a second more needed might be all that is required.

Doc,   for my useage, the access denied error happens 100% randomly. 
   more connections only mean more chances of getting the error, 
but I've had it fail on the very first connection attempt and have 
had several thousand go without errors...   then I'll have 5 within 
a 100 ... there really is no pattern I can detect.

Gabriel, yes the async core makes it harder to make the core synchronous...

my current app is so threaded because of the async core that its 
impressed everyone at the office... I can be scrolling a list view, 
reading files doing sql queries and reading directory lists which 
buildup view menus in real time... everything is fluding and strangely, 
having sql and a loop browsing through several hundred directories 
scanning their content is almost unnoticeable !!!!!!    scrolling 
speed goes down by maybe 20%... but network access remains pretty 
steady... congrats to RT...

@Gab:  no WAIT is used, it is just a wrapper for ease of use.  it 
also selects local db or Rugby

rofl: if you have no wait, then i don't see how you could get that 
code called "concurrently"?

Maxime: Thanks for the info.

Looking at my mysql:// code ('do-handshake and 'read-packet functions), 
I notice that I didn't use any 'wait to synchronize with the server. 
Instead it loops on 'read-io until it gets all the data expected 
which may waste some cpu time. Looking today, I'll say that's not 
the best way to do that, and the code stability could benefit from 
a couple of 'wait calls. I should definitely rewrite the low level 
stuff.

Maxim: if you're guessed right on the access denied issue, you should 
be able to fix it by addind a few 'wait 0.01 to the 'do-handshake 
function. Put one 'wait just before each call to 'read-packet and 
if you have time do some tests.

you're => you've