On 27Jan2013 21:57, Jason Friedman wrote:
| > On 26Jan2013 09:48, Matt Jones wrote:
| > | It sounds like your real problem is with your SQL query... Is that part
of
| > | this problem under your control? Can you break the query into smaller,
| > | quicker, pieces that you can run in a reasonab
> On 26Jan2013 09:48, Matt Jones wrote:
> | It sounds like your real problem is with your SQL query... Is that part of
> | this problem under your control? Can you break the query into smaller,
> | quicker, pieces that you can run in a reasonable amount of time?
>
> Another option to investigate
On 01/26, Matt Jones wrote:
The SQL part is not under control and getting it there requires more
development time than the management is willing to allocate. So this
would be a first step before refactoring that part. I'm aware that the
database might not notice that I don't want to receive the re
I am not sure which database you're using, but all the mainstream RDBMS is
server-client Architecture, when you're running one DML(including the
SELECT), the RDBMS setting up a server process, the query running in that
process instead of your client process, so I guess your problem can solved
in th
hyperboreean writes:
> Here's the use case I want to implement - I have to generate a report
> from multiple database servers. This report should be generated every 2
> hours. Sometimes it happens that a query on one of the database servers
> takes longer than expected and impedes the generation
On 26Jan2013 09:48, Matt Jones wrote:
| It sounds like your real problem is with your SQL query... Is that part of
| this problem under your control? Can you break the query into smaller,
| quicker, pieces that you can run in a reasonable amount of time?
Another option to investigate is whether
It sounds like your real problem is with your SQL query... Is that part of
this problem under your control? Can you break the query into smaller,
quicker, pieces that you can run in a reasonable amount of time?
If not, nesting threads might be your best programmatic solution. Heed
Jason's warni
> Sometimes it happens that a query on one of the database servers
> takes longer than expected and impedes the generation of this report
> (that's right, the queries are ran sequential). What I am trying to
> achieve is to parallelize the queries on each database server and to be
> able to cancel
Here's the use case I want to implement - I have to generate a report
from multiple database servers. This report should be generated every 2
hours. Sometimes it happens that a query on one of the database servers
takes longer than expected and impedes the generation of this report
(that's right, t
