Results 1 to 7 of 7
  1. #1
    2 Star Lounger
    Join Date
    Jul 2002
    Location
    North Dakota, USA
    Posts
    184
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Correct way to close/kill variables? (2000)

    What is the correct way to close each type variable? I want to clear the values that are stored in them so they can be used the next time they are called. Also how would I clear them from memory?

    for example:

    dim dtDate as Date
    dim intInteger as Integer
    dim sngSingle as Single
    dim lngLong as Long
    dim strString as String

    Do you set the variable to Nothing or vbNullString or what?

    Thanks.
    Sarah

  2. #2
    5 Star Lounger
    Join Date
    Jan 2001
    Location
    Vancouver, Br. Columbia, Canada
    Posts
    632
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Correct way to close/kill variables? (2000)

    There is no need to close these simple variables. As a matter of good programming practice, you should initialize variables before use. Not strictly required, but can sometimes eliminate subtle bugs. For example:

    dim sInput as string
    dim i as integer
    sInput = ""
    for i = 1 to 10
    sInput = sInput & "some other stuff"
    next i

    Only Object variables need to be removed. For example:

    dim db as dao.database
    set db = currentdb
    ...
    set db = nothing
    --------------------------------------------------
    Jack MacDonald
    Vancouver, Canada

  3. #3
    2 Star Lounger
    Join Date
    Jul 2002
    Location
    North Dakota, USA
    Posts
    184
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Correct way to close/kill variables? (2000)

    I understand about the recordset type and initializing variables, I know how to do that.

    But it won't affect performance if I leave string, date, integer, single, and long variables with values still in them when I exit a subprocedure? I thought it was good practice was to clean up the variables upon exit.

    Sarah

  4. #4
    5 Star Lounger
    Join Date
    Jan 2001
    Location
    Vancouver, Br. Columbia, Canada
    Posts
    632
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Re: Correct way to close/kill variables? (2000)

    No - If they are declared in the subroutine, then they will die when the subroutine is finished.
    --------------------------------------------------
    Jack MacDonald
    Vancouver, Canada

  5. #5
    Bronze Lounger
    Join Date
    Nov 2001
    Location
    Arlington, Virginia, USA
    Posts
    1,394
    Thanks
    0
    Thanked 3 Times in 3 Posts

    Re: Correct way to close/kill variables? (2000)

    As noted, variables will retain some value until they go out of scope. A procedure-level variable will go out of scope when routine exits. (An exception is a variable declared as Static, which retains its value between calls to the procedure.) A module-level variable remains in scope (and consume resources) as long as any code in module is running. Module-level variables in a class module will remain in scope as long as an instance of the class remains in memory as an object. So avoid unnecessary module-level or Static variables.

    As noted, object variables should be set to Nothing once they have served their purpose. Note that more than one object variable can point to the same object. The memory and system resources associated with the object are NOT released until all object variables pointing to it have been set to Nothing.

    An array variable can be "erased" using the Erase statement. If the array is fixed-size, the elements of the array are re-initialized by the Erase statement; but this does not recover memory. (For example, an Integer variable will require 2 bytes of memory whether its value is 0 or 32,767.) The memory allocated to a dynamic array, however, is released by the Erase statement. So arrays should be "erased" once they have served their purpose. Use of Redim Preserve when redimensioning an array is resource-intensive so should be avoided if possible.

    To conserve memory use, also recommend avoid Variant variables whenever possible and use correct data type for task in question. Avoid unnecessary string variables; the VB string data type (BSTR) consumes a lot of resources. Also, pass variable arguments by reference (ByRef - the default in VB) unless it's necessary to pass by value (ByVal).

    HTH

  6. #6
    Plutonium Lounger
    Join Date
    Dec 2000
    Location
    Sacramento, California, USA
    Posts
    16,775
    Thanks
    0
    Thanked 1 Time in 1 Post

    Re: Correct way to close/kill variables? (2000)

    <hr>Avoid unnecessary string variables<hr>
    I think you'll have to qualify "unnecessary", Mark. If using a string variable makes the code more readable or allows you to debug it more easily, then it isn't unnecessary. And I question whether using a string variable is unnecessary when it eliminates multiple object references in conditional statements.
    Charlotte

  7. #7
    Bronze Lounger
    Join Date
    Nov 2001
    Location
    Arlington, Virginia, USA
    Posts
    1,394
    Thanks
    0
    Thanked 3 Times in 3 Posts

    Re: Correct way to close/kill variables? (2000)

    I wasn't trying to imply you shouldn't use string variables, but that you should not use them unnecessarily or inefficiently. I use string variables all the time. This is simplified example of a sub used to generate SQL on the fly:

    Private Sub GetSQL(ByRef intOpt As Integer)
    On Error GoTo Err_Handler

    Dim strSQL As String
    Dim strSelect As String
    Dim strFrom As String
    Dim strWhere As String
    Dim strOrderBy As String

    ' Generate SELECT clause...
    strSQL = strSelect

    ' Generate FROM clause...
    strSQL = strSQL & " " & strFrom

    ' Generate WHERE clause...
    strSQL = strSQL & " " & strWhere

    ' Generate ORDER BY clause...
    strSQL = strSQL & " " & strOrderBy & ";"

    Me.Text_SQL = strSQL

    ' Preferred:
    Me.Text_SQL = strSelect & " " & strFrom & " " & _
    strWhere & " " & strOrderBy & ";"


    End Sub

    In above example there's no need to re-concatenate the strSQL variable after each step. I would often find myself guilty of this type of thing, when it is simpler to concatenate the SQL string once and then assign to textbox directly; the strSQL variable served no other purpose. Using a separate variable for each clause of the SQL statement makes it simple to concatenate once each part of statement has been generated. Anyway that's what I meant by "unnecessary" string variables.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •