On Jan 28, 2009, at 7:10 AM, Marco Zanoli wrote:
Hi I just started using pgSQL4RB. I'm trying to query my database, but
I get no records.
The same query in pgAdmin works and returns 127 records.
Postgresql version 8.3.5 on Windows 2003 enterprise server. Can anyone
help me?
On Jan 29, 2009, at 4:53 AM, Marco Zanoli wrote [to ***@aliacta.com]:
Godd morning. I'm trying your classes in my realbasic pro 2007r5. I
need a stable way to
access a database from inside a thread (I use MonkeyBread Thread
plugin), but using your
class I get a StackOverflow when I try to Connect.
Is this a known problem? Or is it impossible to do?
Hi Marco!
Here's the bad news: as a rule of thumb, it is not recommended to send
queries from
threads.
Whether this will work is entirely depending on the version of RB you
use and since you
throw in the MB plugin that only makes the cocktail more explosive.
pgSQL4RB is pure,
native RB code: it is not an external plugin and therefore it is
extremely stable and
compatible with RB. However the pgSQL4RBsocket is a subclass of the
TCPIPSocket, and
therefore not officially supported by REAL Software to work with threads.
There is of course, another extremely good reason not to send queries
from threads: you
would never know when exactly and in which order queries from
different threads are sent!
It's the best way to mingle things up in an inextricable web of
debugging horror.
Here's the good news: you may use threads to process the results of
your queries.
Here's the excellent news: pgSQL4RB is kind of a thread in itself, it
uses zero processor
power while waiting for results from the server for instance, and it
doesn't hold back
your other code from running during that time.
So YES, pgSQL4RB is the right choice once you're thinking of threaded
or more exactly
asynchronous access to PostgreSQL. This behavior is precisely one of
the mayor strengths
of pgSQL4RB! Below is my advice for the overall architecture of your
application--based
on what I know about it now, which is near zero, feel free to tell me
more about it if
necessary.
Whenever you feel like using a thread to do something with PostgreSQL,
DON'T! Just send
the query from a (subclass of a) pgSQLsimpleCache instead. In the
lines of code after
this, you can simply continue to give commands as if the query were a
thread! These
commands will execute immediately, regardless of how much time it
takes until records are
being received!
Put the code that deals with the received records in the DataReceived
event of the
pgSQLsimpleCache. This event is triggered as soon as the records are
received and
chances are that it will work just as fast (or maybe faster) if you
don't launch a thread
from in there either!
Success,
Marc
PS: to experiment and see how things will work, try the following (in
pseudo code):
in your main code:
1. send query
2. do some random heavy operations that will take a long time to
complete (not just
delaying, but something for real)
3. note the time at which this completes
in your DataReceived event:
1. do some manipulations with the records (do this from a thread or not)
2. note the time at which this completes
All you have to do is play around with how heavy you make the
operations and data
manipulations and then compare the two time stamps to see how
'threaded' it all behaves!
PPS: read the chapter on Troubleshooting starting on page 120 of the
manual to gain
awareness of a lot of other tidbits similar to 'avoid threads'.
PPPS: I do not have frequent access to the internet for the time
being so please be
patient when expecting a reply. I apologize on forehand for any delays.