I guess you need to run a timer in the same dataSession to check for
cursor availability
thn
Le 26/01/12 21:49, MB Software Solutions General Account a écrit :
vfp9sp2
I've got lots of SQLEXECs to fire off and I didn't want to wait for each
one to finish before firing off the next one. Are
On Fri, Jan 27, 2012, at 10:07 AM, Thierry Nivelet wrote:
Are there any gotchas I
should be aware of by taking the SQLSETPROP(giHandle,'Asynchronous',.T.)
route?
I think you need to repeatedly call SQLExec(), it will return 0 while
still executing, 1 when complete, or -1 if something went
Mike:
What Christof said.
1) You'll need a separate connection for each running SQLEXEC.
2) Unless you have a super-powerful multi-thread server running highly
parallel queries, you may not gain very much. Two at once might work
fairly well, but I doubt if it's worth inventing a fancy
On Fri, Jan 27, 2012 at 11:47 AM, Dan Covill dcov...@san.rr.com wrote:
Mike:
What Christof said.
1) You'll need a separate connection for each running SQLEXEC.
2) Unless you have a super-powerful multi-thread server running highly
parallel queries, you may not gain very much. Two at once
On 1/27/2012 5:47 AM, Christof Wollenhaupt wrote:
Hi Mike,
The connection is busy while the query is still executing. You therefore
need a separate connection for each query or send multiple statements in
one batch if the server supports this. This could be an issue if you have
transactions
On 1/27/2012 3:58 PM, Stephen Russell wrote:
Could the many different scripts be done via a single SPROC instead of
5,15,25 different statements?
I think of a process like EOM that may not only update thousands of
transactions because of a variety of reasons, but also pull a dataset
back to
6 matches
Mail list logo
