mlcktmguy
asked on
Extracting records from DB. Extract from full table or query.
I am looking at and trying to improve an Access 2003 application that was developed a while ago. Eventually moving it to Access 2013.
There are a lot of subroutine and functions in this application whose sole purpose its to pull a subset of information from one record in the table based on some passed selection criterion, usually a record ID.
In some of the routines the developer is selecting records from a query, in others they are selecting from the actual access table in the backed mdb.
In the example below the user want information from exactly 1 record in a table of about 500,000 records. There is no updating, just pulling the information on the record. The fields needed from the record are a subset of all of the fields on the record. In this case the user is selecting the fields from the entire table 'tblTaxRecs '. In similar situations I always create a query with the subset of fields needed and select from the query rather than the full table.
My question: I always thought it was more efficient to use a query on the main table, with only the fields needed, instead of selecting from the entre table. Am I right? It's easy enough to create one query and change this code to select from the new query but this is only one of dozens like this in the application. It would take some time to find them all and change them. Just wondering if from an efficient processing standpoint it is worth the effort
.
If anyone has other ideas to make this routine more efficient please let me know.
Here it is:
There are a lot of subroutine and functions in this application whose sole purpose its to pull a subset of information from one record in the table based on some passed selection criterion, usually a record ID.
In some of the routines the developer is selecting records from a query, in others they are selecting from the actual access table in the backed mdb.
In the example below the user want information from exactly 1 record in a table of about 500,000 records. There is no updating, just pulling the information on the record. The fields needed from the record are a subset of all of the fields on the record. In this case the user is selecting the fields from the entire table 'tblTaxRecs '. In similar situations I always create a query with the subset of fields needed and select from the query rather than the full table.
My question: I always thought it was more efficient to use a query on the main table, with only the fields needed, instead of selecting from the entre table. Am I right? It's easy enough to create one query and change this code to select from the new query but this is only one of dozens like this in the application. It would take some time to find them all and change them. Just wondering if from an efficient processing standpoint it is worth the effort
.
If anyone has other ideas to make this routine more efficient please let me know.
Here it is:
Public Sub getTaxRecInfoFromIDForOverlay(passedTaxRecID As Long, _
returnTaxHeaderID As Long, _
returnPropertyID As Long, _
returnBRT As Long, _
returnTaxYear As Long, _
returnPrincipalAmt As Double, _
returnInterestAmt As Double, _
returnPenaltyAmt As Double, _
returnLienCost As Double, _
returnAttyFeesAmt As Double, _
returnYearTotal As Double, _
returnPayStatusID As Long)
'
selectString = "Select Top 1 [TaxHeaderID], [PropertyID], [BRT], [TaxYear], [PrincipalAmt], [PenaltyAmt], [InterestAmt], [LienCost], [AttyFeesAmt], [PayStausID] " & _
" From tblTaxRecs Where [ID] = " & passedTaxRecID
'
Dim rs As ADODB.Recordset
Set rs = New ADODB.Recordset
rs.Open selectString, CurrentProject.Connection, adOpenForwardOnly, adLockOptimistic
If rs.EOF Then
Else
'
returnTaxHeaderID = Nz(rs!TaxHeaderID, 0)
returnPropertyID = Nz(rs!PropertyID, 0)
returnBRT = Nz(rs!BRT, 0)
returnTaxYear = Nz(rs!TaxYear, 0)
returnPrincipalAmt = Nz(rs!PrincipalAmt, 0)
returnInterestAmt = Nz(rs!InterestAmt, 0)
returnPenaltyAmt = Nz(rs!PenaltyAmt, 0)
returnLienCost = Nz(rs!LienCost, 0)
returnAttyFeesAmt = Nz(rs!AttyFeesAmt, 0)
returnYearTotal = Round(returnPrincipalAmt + returnInterestAmt + returnPenaltyAmt + returnLienCost + returnAttyFeesAmt, 2)
returnPayStatusID = Nz(rs!PayStausID, 0)
End If
'
rs.Close
Set rs = Nothing
End Sub
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
I agree with Scott that your time on the 2003->2013 conversion should be spent elsewhere. I found that most of the work involved getting forms to function in 2013 the way the user expected them to behave in 2003. The most frustrating for me were default values, which I had to code. The default value in the properties window no longer worked after migration.
ASKER
Thanks.
alkimark: May I ask a follow up on a different topic. You mention
<< The most frustrating for me were default values, which I had to code. The default value in the properties window no longer worked after migration. >>
I ran into the same thing in another application I am converting. Did you have any other issues migrating to 2013? When I began my first conversion I posted a question on experts exchange asking what issues to expect when moving from 2003 to 2013. Other than the new menu system, no one mentioned the default values. When I encountered that issue I thought I had done something wrong or had missing references but couldn't find any. Just curious if you encountered anything else, especially since you ran into the default value issue.
alkimark: May I ask a follow up on a different topic. You mention
<< The most frustrating for me were default values, which I had to code. The default value in the properties window no longer worked after migration. >>
I ran into the same thing in another application I am converting. Did you have any other issues migrating to 2013? When I began my first conversion I posted a question on experts exchange asking what issues to expect when moving from 2003 to 2013. Other than the new menu system, no one mentioned the default values. When I encountered that issue I thought I had done something wrong or had missing references but couldn't find any. Just curious if you encountered anything else, especially since you ran into the default value issue.
Your migration problem(s) warrants a new question on just that subject.
ASKER
I agree, here it is.
New Question on Migrating Access 2003 to Access 2013
New Question on Migrating Access 2003 to Access 2013