Link to home
Start Free TrialLog in
Avatar of mlcktmguy
mlcktmguyFlag for United States of America

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:
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

Open in new window

ASKER CERTIFIED SOLUTION
Avatar of aikimark
aikimark
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
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.
Avatar of mlcktmguy

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.
Your migration problem(s) warrants a new question on just that subject.