Question

I am hitting a brick wall with something I’m trying to do.

I’m trying to perform a complex query and return the results to a vbscript (vbs) record set.

In order to speed up the query I create temporary tables and then use those tables in the main query (creates a speed boost of around 1200% on just using sub queries)

the problem is, the outlying code seems to ignore the main query, only ‘seeing’ the result of the very first command (i.e. it will return a ‘records affected’ figure)

For example, given a query like this..

delete from temp
select * into temp from sometable where somefield = somefilter

select sum(someotherfield) from yetanothertable where account in (select * from temp)

The outlying code only seems to ‘see’ the returned result of ‘delete from temp’ I can’t access the data that the third command is returning.

(Obviously the sql query above is pseudo/fake. the real query is large and it’s content not relevant to the question being asked. I need to solve this problem as without being able to use a temporary table the query goes from taking 3 seconds to 6 minutes!)

edit: I know I could get around this by making multiple calls to ADODB.Connection’s execute (make the call to empty the temp tables, make the call to create them again, finally make the call to get the data) but I’d rather find an elegant solution/way to avoid this way of doing it.

edit 2: Below is the actual SQL code I’ve ended up with. Just adding it for the curiosity of people who have replied. It doesn’t use the nocount as I’d already settled on a solution which works for me. It is also probably badly written. It evolved over time from something more basic. I could probably improve it myself but as it works and returns data extremely quickly I have stuck with it. (for now)

Here’s the SQL.

Here’s the Code where it’s called. My chosen solution is to run the first query into a third temp table, then run a select * on that table from the code, then a delete from from the code…

I make no claims about being a ‘good’ sql scripter (self taught via necesity mostly), and the database is not very well designed (a mix of old and new tables. Old tables not relational and contain numerical values and date values stored as strings)

Here is the original (slow) query…

    select 
name,
program_name,
sum(handle) + sum(refund) as [Total Sales],
sum(refund) as Refunds,
sum(handle) as [Net Sales],
sum(credit - refund) as Payout,
cast(sum(comm) as money) as commission
from 

(select accountnumber,program_name,
cast(credit_amount as money) as credit,cast(refund_amt as money) as refund,handle, handle * (
(select commission from amtotecommissions 
where _date = a._date 
and pool_type = (case when a.pool_type in ('WP','WS','PS','WPS') then 'WN' else a.pool_type end)
and program_name = a.program_name) / 100) as comm

from amtoteaccountactivity a where _date = '@yy/@mm/@dd' and transaction_type = 'Bet'
and accountnumber not in ('5067788','5096272') /*just to speed the query up a bit. I know these accounts aren't included*/
) a,

ews_db.dbo.amtotetrack t
where (a.accountnumber in (select accountno from ews_db.dbo.get_all_customers where country = 'US')
or a.accountnumber in ('5122483','5092147'))
and t.our_code = a.program_name collate database_default
and t.tracktype = 2


group by name,program_name

Answer 1

I suspect that with the right SQL and indexes you should be able to get equal performance with a single SELECT, however there isn’t enough information in the original question to be able to give guidance on that.

I think you’ll be best of doing this as a stored procedure and calling that.

CREATE PROCEDURE get_Count 
@somefilter int
AS
delete from temp;
select * into temp from sometable where somefield = @somefilter;

select sum(someotherfield) from yetanothertable 
where account in (select * from temp);

However an example avoiding the IN the way you’re using it via a JOIN will probably fix the performance issue. Use EXPLAIN SELECT to see what’s going on and optimise from there. For example the following

select sum(transactions.value) from transactions
inner join user on transactions.user=user.id where user.name='Some User'

is much quicker than

select sum(transactions.value) from transactions
where user in (SELECT id from user where user.name='Some User')

because the amount of rows scanned in the second example will be the entire table, whereas in the first the indexes can be used.

---

Rev1

Taking the slow SQL posted it is appears that there are full table scans going on where the SQL states WHERE .. IN e.g.

where (a.accountnumber in (select accountno from ews_db.dbo.get_all_customers))

The above will pull in lots of records which may not be required. This together with the other nested table selects are not allowing the optimiser to pull in only the records that match, as would be the case when using JOIN at the outer level.

When building these type of complex queries I generally start with the inner detail, because we need to have the inner detail so we can perform joins and aggregate operations.

What I mean by this is if you have a typical DB with customers that have orders that create transactions that contain items then I would start with the items and pull in the rest of the detail with joins.

By way of example only I suggest building the query more like the following:

select name,
  program_name,
  SUM(handle) + SUM(refund) AS [Total Sales],
  SUM(refund) AS Refunds,
  SUM(handle) AS [Net Sales],
  SUM(credit - refund) AS Payout,
  CAST(SUM(comm) AS money) AS commission,

FROM ews_db.dbo.get_all_customers AS cu
 INNER JOIN amtoteactivity AS a ON a.accoutnumber = cu.accountnumber
 INNER JOIN ews_db.dbo.amtotetrack AS track ON track.our_code = a.program_name
 INNER JOIN amtotecommissions AS commision ON co.program_name = a.program_name

WHERE customers.country='US'
  AND t.tracktype = 2
  AND a.transaction_type = 'Bet'
  AND a._date = ''@yy/@mm/@dd'
  AND a.program_name = co.program_name
  AND co.pool_type = (case when a.pool_type in ('WP','WS','PS','WPS') then 'WN' else a.pool_type end)

GROUP BY name,program_name,co.commission

NOTE: The above is not functional and is for illustration purposes. I’d need to have the database online to build the real query. I’m hoping you’ll get the general idea and build from there.

My top tip for complex queries that don’t work is simply to completely start again throwing away what you’ve already got. Sometimes I will do this three or four times when building a really tricky query.

Always build these queries gradually starting from the most detail and working outwards. Inspect the results at each stage because it helps visualise what the data are.