DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 10 of 10

Thread: GC and DB objects?

  1. #1
    Richard Curzon Guest

    GC and DB objects?

    Related to the topic (if not the intent)... what are some real VB focussed
    effects not discussed yet?

    Two facts could be lined up to see how they play together. (I haven't had a
    close enuf look yet myself):

    1 - 80% of VB apps have been database related historically
    2 - Yet Another Different data model is being sold along with dot-net, I
    wonder if MS are being totally honest about the reasons, are they hiding a
    big DF conversion problem?

    When a VB6 Database object or Recordset object went out of scope in a VB6
    program, the real object in the service was closed and cleaned up
    automatically.

    Now if you use the COM-based ADO Databases and Recordset in VB.net, and let
    them go exit scope without complete cleanup, I assume the actual service
    object is held open for an indeterminate time..

    Now it's considered good VB6 form to cleanup manually, and most programs do
    so in the main line at least. But since the runtime cleans up anyway, it's
    difficult to determine how complete and robust the cleanup is.

    In fact, I bet 90% of DB programs do not handle all cleanup completely and
    robustly in complex situations, like error handling. Which problems didn't
    matter in VB6, but will in dot-net.

    The new ADO.net proposes a lot more disconnected record management. They
    want users to do updates via stored procs rather than live updatable
    cursors. Could there reasons have something to do with the DF issue?

    regards
    Richard.

    -----
    Live without dead time - Raoul Vaneigem



  2. #2
    Mark Burns Guest

    Re: GC and DB objects?


    "Richard Curzon" <ssi@interNOSPAMlog.com> wrote in message
    news:3a422d5c@news.devx.com...
    > Related to the topic (if not the intent)... what are some real VB

    focussed
    > effects not discussed yet?
    >
    > The new ADO.net proposes a lot more disconnected record management. They
    > want users to do updates via stored procs rather than live updatable
    > cursors. Could there reasons have something to do with the DF issue?
    >


    HEY! HEY! You there! Stop that!
    I said PUT THAT CURTAIN BACK DOWN and LEAVE THAT MAN BEHIND IT ALONE!<g>



  3. #3
    Larry Triezenberg Guest

    Re: GC and DB objects?

    This has always (as far as I can tell) been the case with ADO (if that helps any
    <g>). Orphaned objects were/are often held open for an indeterminant period of
    time if everything was/is not closed out properly...

    "Richard Curzon" <ssi@interNOSPAMlog.com> wrote in message
    news:3a422d5c@news.devx.com...
    > Now if you use the COM-based ADO Databases and Recordset in VB.net, and let
    > them go exit scope without complete cleanup, I assume the actual service
    > object is held open for an indeterminate time..




  4. #4
    Jonathan Allen Guest

    Re: GC and DB objects?

    > 2 - Yet Another Different data model is being sold along with dot-net, I
    > wonder if MS are being totally honest about the reasons, are they hiding a
    > big DF conversion problem?


    They are not hiding it. In fact, they have been very open about the whole
    matter and are working on new syntax to help with that very problem.

    --
    Jonathan Allen


    "Richard Curzon" <ssi@interNOSPAMlog.com> wrote in message
    news:3a422d5c@news.devx.com...
    > Related to the topic (if not the intent)... what are some real VB

    focussed
    > effects not discussed yet?
    >
    > Two facts could be lined up to see how they play together. (I haven't had

    a
    > close enuf look yet myself):
    >
    > 1 - 80% of VB apps have been database related historically
    > 2 - Yet Another Different data model is being sold along with dot-net, I
    > wonder if MS are being totally honest about the reasons, are they hiding a
    > big DF conversion problem?
    >
    > When a VB6 Database object or Recordset object went out of scope in a VB6
    > program, the real object in the service was closed and cleaned up
    > automatically.
    >
    > Now if you use the COM-based ADO Databases and Recordset in VB.net, and

    let
    > them go exit scope without complete cleanup, I assume the actual service
    > object is held open for an indeterminate time..
    >
    > Now it's considered good VB6 form to cleanup manually, and most programs

    do
    > so in the main line at least. But since the runtime cleans up anyway,

    it's
    > difficult to determine how complete and robust the cleanup is.
    >
    > In fact, I bet 90% of DB programs do not handle all cleanup completely and
    > robustly in complex situations, like error handling. Which problems

    didn't
    > matter in VB6, but will in dot-net.
    >
    > The new ADO.net proposes a lot more disconnected record management. They
    > want users to do updates via stored procs rather than live updatable
    > cursors. Could there reasons have something to do with the DF issue?
    >
    > regards
    > Richard.
    >
    > -----
    > Live without dead time - Raoul Vaneigem
    >
    >




  5. #5
    Michael \(michka\) Kaplan Guest

    Re: GC and DB objects?

    Jonathan,

    Your obtsuity is showing! :-)

    The half joking/half serious point being made was that maybe the
    recommendations to use ADO.NET insetad of ADO are based on issues with DF
    problems in the ADO world due to COM compatibility issues?

    --
    MichKa

    a new book on internationalization in VB at
    http://www.i18nWithVB.com/

    "Jonathan Allen" <greywolfcs@bigfoot.com> wrote in message
    news:3a42773c@news.devx.com...
    > > 2 - Yet Another Different data model is being sold along with dot-net, I
    > > wonder if MS are being totally honest about the reasons, are they hiding

    a
    > > big DF conversion problem?

    >
    > They are not hiding it. In fact, they have been very open about the whole
    > matter and are working on new syntax to help with that very problem.
    >
    > --
    > Jonathan Allen
    >
    >
    > "Richard Curzon" <ssi@interNOSPAMlog.com> wrote in message
    > news:3a422d5c@news.devx.com...
    > > Related to the topic (if not the intent)... what are some real VB

    > focussed
    > > effects not discussed yet?
    > >
    > > Two facts could be lined up to see how they play together. (I haven't

    had
    > a
    > > close enuf look yet myself):
    > >
    > > 1 - 80% of VB apps have been database related historically
    > > 2 - Yet Another Different data model is being sold along with dot-net, I
    > > wonder if MS are being totally honest about the reasons, are they hiding

    a
    > > big DF conversion problem?
    > >
    > > When a VB6 Database object or Recordset object went out of scope in a

    VB6
    > > program, the real object in the service was closed and cleaned up
    > > automatically.
    > >
    > > Now if you use the COM-based ADO Databases and Recordset in VB.net, and

    > let
    > > them go exit scope without complete cleanup, I assume the actual service
    > > object is held open for an indeterminate time..
    > >
    > > Now it's considered good VB6 form to cleanup manually, and most programs

    > do
    > > so in the main line at least. But since the runtime cleans up anyway,

    > it's
    > > difficult to determine how complete and robust the cleanup is.
    > >
    > > In fact, I bet 90% of DB programs do not handle all cleanup completely

    and
    > > robustly in complex situations, like error handling. Which problems

    > didn't
    > > matter in VB6, but will in dot-net.
    > >
    > > The new ADO.net proposes a lot more disconnected record management.

    They
    > > want users to do updates via stored procs rather than live updatable
    > > cursors. Could there reasons have something to do with the DF issue?
    > >
    > > regards
    > > Richard.
    > >
    > > -----
    > > Live without dead time - Raoul Vaneigem
    > >
    > >

    >
    >
    >




  6. #6
    Sjoerd Verweij Guest

    Re: GC and DB objects?

    > Now if you use the COM-based ADO Databases and Recordset in VB.net, and
    > let them go exit scope without complete cleanup, I assume the actual

    service
    > object is held open for an indeterminate time..


    Yes. Just out of curiosity, how hard do you think a bug like this would be
    to find? I've already forgotten Dispose() / Close() around twenty times, and
    it turns out to be just so obvious and easy to fix...




  7. #7
    Richard Curzon Guest

    Re: GC and DB objects?

    > Yes. Just out of curiosity, how hard do you think a bug like this would be
    > to find? I've already forgotten Dispose() / Close() around twenty times,

    and
    > it turns out to be just so obvious and easy to fix...


    If you forgot it around 20 times, how did you find the problem? By the fact
    that your actual execution path failed to clean up, am I right?

    So... if your actual execution MIGHT sometimes be an exception path... or
    one of 20 different exception paths.... you'd have to test all those too.
    Now maybe it makes a difference?

    Of course anything is possible once you accept the price of dot-net is pain
    for some things.... it's just a question of haggling over the price <g>

    regards
    Richard.



  8. #8
    Sjoerd Verweij Guest

    Re: GC and DB objects?

    > If you forgot it around 20 times, how did you find the problem? By the
    fact
    > that your actual execution path failed to clean up, am I right?


    Okay, say this is a database connection that stays open. You do a global
    search for connection to see where it's opened, and scroll down to see if
    there's a Finally clause/closing event which closes it. If not, add it. Even
    if your code is convoluted, even if it has all this stuff declared at module
    level, it should take you no more than 2 minutes to check and 5 minutes to
    fix each (even assuming you do this before your morning coffee). So, AT
    WORST, assuming you have screwed up twenty times, all this can be fixed in a
    few hours.





  9. #9
    Richard Curzon Guest

    Re: GC and DB objects?

    > So, AT
    > WORST, assuming you have screwed up twenty times, all this can be fixed in

    a
    > few hours.


    Well it's just the same as the C++ guys who are telling us we don't need GC
    anyway. If you can't manage to clean up your objects in all exception
    paths, you aren't a Real Programmer. You need one of those toy GC languages
    like Smalltalk... or VB6... or dot-net (we once thought) <g>

    But with dot-net, no more toys, I guess we all have to be Real Programmers
    now!

    I only hope the new objects are more informative about their state in
    exception paths than DAO and ADO.

    In many handlers you weren't sure *exactly* what caused the error, and
    therefore you don't know what state each possible (maybe nested) resource
    might be in when you try to clean it up. E.g. ... how do you tell if a
    recordset is open? Many times you just had to try to close it and catch the
    error. Is there an IsOpen method/property that tells you the state in
    dot-net, stuff like that? If we need even more errors handlers, within
    error handlers, within... that's when the fun really starts to drain off
    <g>...

    (or you might have 20-deep nested SEHs, nobody can figure out what the
    routine does... just like it looks like it can't ever have an unhandled
    exception <g>)

    I suppose we'll each have our own generic cleanup methods, for the real
    bail-out-and-please-try-later cases. Just before we let go of our
    references, iterate over all possible nested resources, make sure they are
    all closed and cleaned up, handling all possible errors in one place. We
    could tolerate some inefficiency if only for those "bail" paths.

    regards
    Richard.





  10. #10
    Sjoerd Verweij Guest

    Re: GC and DB objects?

    > Well it's just the same as the C++ guys who are telling us we don't need
    GC
    > anyway. If you can't manage to clean up your objects in all exception
    > paths, you aren't a Real Programmer.


    No, it is completely differrent. In VB.NET, you risk losing resources such
    as handles, database connections or have lingering UI elements. Easy to
    find. Compare to malloc().

    > I suppose we'll each have our own generic cleanup methods, for the real
    > bail-out-and-please-try-later cases. Just before we let go of our
    > references, iterate over all possible nested resources, make sure they are
    > all closed and cleaned up, handling all possible errors in one place. We
    > could tolerate some inefficiency if only for those "bail" paths.


    You mean thread handlers?

    Anyway, if you designed your objects correctly, you shouldn't have a problem
    with nested resources anyway. For example, if you get involved like this:

    Class A
    Arr As B()
    End Class

    Class B
    Arr As C()
    End Class

    Class C
    X As SomeTypeOfResource
    End Class

    All of these should have Dispose() of their own. B's Dispose should call C's
    Dispose. If you're not doing that, it's back to the drawing board anyway :-)




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center