Member Login

Username
Password
Forget Password
New Sign Up
Search Forum

Buy Support
Incidents

If you can't find your answer in the FREE PUBLIC QDeveloper Forum, require URGENT Priority Support, or you need to send us private or confidential information:

Click Here
If you can't login and post questions or you are having trouble viewing forum posts:
Click Here
Callback
Support

If you live in USA, UK, Canada, Australia or New Zealand, you can leave us details on your question and request us to call you back and discuss them with you personally  (charges apply).

Click Here
 
Buy Support
Incidents
If you can't find your answer in the FREE PUBLIC QDeveloper Forum, require URGENT Priority Support, or you need to send us private or confidential information:
Click Here

Forum : Important Select Query Speed QuestionSearch Forum

Forum Home > QODBC - ODBC Driver for QuickBooks > QODBC v9 Forum

 New Topic 
 
 Post Reply 
[1]  
 Important Select Query Speed Question 
 Author   Message 
  PH 
  
 Group: Members 
 Posts: 41 
 Joined: 2007-02-02 
 Profile
 Posted : 2008-11-04 05:08:59

I'm about to start a project using QODBC and I need your advice as to which provides the best query speed or whether there is anything I can do to improve the speed.

I am writing a cash flow application in Excel with ADO.  Each cell will have a custom function that results in a QODBC SELECT query and there may be hundreds of function calls.  I need your advice as to which one of these methods I should use (see examples below).

Option 1 - Query transaction table with JOIN.  For me takes 1.15 secs per query (So 500 queries would take 10 min ... too long)

Option 2 - Query a report to try to get the same data 0.35 secs per query, so 500 queries will take 3 min.  Much faster, but harder to code and the resulting code is a lot harder to understand.

Option 3 - Do one Query, return the recordset to Excel, using EXCEL functions or even ADO to perform subsequent queries in memory.  Speed is nearly instant but its a lot more coding and somewhat defeats the purpose of the direct connect with QODBC.  Snapshot is fine, but I had hoped to avoid a lot of SUMIFS, SUMPRODUCT, VLOOKUP formulae, but I'm leaning this way.

Option 4 - Use the transaction table so that no JOIN is needed.  I've not tried this yet.

Option 5 - Something else I had overlooked and the nature of this posted question?????

Obviously, I would use Option 1 if it were faster.

In the example below, I need to filter on account.  If I use the BILL table, account is not available.  If I use BilIItemLine, the account is still not available unless I join to Item table, which appears to take a long time.  I removed the account filter just to test the rest of the query speed, but that is the reason for my join.

Example of Option 1 - 1.15 seconds per query.

vSQL = "Select sum(itemlineamount) as vTotal " _
& "from BillItemLine Inner Join Item on BillItemLine.ItemLineItemRefListID = Item.ListID Where BillItemLine.IsPaid = False " _
& "and TxnDate >= " & "{d'" & Format(date1, "yyyy-mm-dd") & "'}" & " And TxnDate <= " & "{d'" & Format(date2, "yyyy-mm-dd") & "'}"

Example of Option 2 - 0.35 seconds per query

vSQL = "sp_report CustomTxnDetail show sum(amount) as vTotal parameters DateFrom = " _
& "{d'" & Format(date1, "yyyy-mm-dd") & "'} " & ", DateTo =  " & "{d'" & Format(date2, "yyyy-mm-dd") & "'} " _
& ", TxnFilterTypes = 'Bill' " _
& ", SummarizeRowsBy = 'TotalOnly' Where PaidStatus='Unpaid'"

 

  Top 
  Tom 
  6c3c1_sdk-qodbc.gif
 Group: Administrator 
 Posts: 5510 
 Joined: 2006-02-17 
 Profile
 Posted : 2008-11-05 13:48:42

This should speed up Option 1:

vSQL = "Select sum(itemlineamount) as vTotal " _
& "from BillItemLine NOSYNC, Item NOSYNC where BillItemLine.ItemLineItemRefListID = Item.ListID and BillItemLine.IsPaid = False " _
& "and TxnDate >= " & "{d'" & Format(date1, "yyyy-mm-dd") & "'}" & " And TxnDate <= " & "{d'" & Format(date2, "yyyy-mm-dd") & "'}"

 

  Top 
  PH 
  
 Group: Members 
 Posts: 41 
 Joined: 2007-02-02 
 Profile
 Posted : 2008-11-05 15:09:34

Thanks for the excellent suggestion.

That took Option 1 from 1.15 secs per query to 0.2 second per query, faster than the SP equivalent.

So, 500 queries would take 1.6 minutes. 

I tried Option 3 using ADO and it's instant (since everything is in RAM), but a lot more coding and error-prone..  ADO with Excel has a known bug where it tests the first 8 to 16 rows to determine if a field is numeric or text and, unfortunately, defaults to text instead of numeric.  SUMIF and SUMPRODUCT formulae are messy and hard to read.

So, I think Option 1 is best. 

Support on this forum is really excellent.  Thanks.

 

  Top 
 New Topic 
 
 Post Reply 
[1]  

Jump to