DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 14 of 14

Thread: movenext & moveprevious issue

  1. #1
    Join Date
    Feb 2008
    Posts
    6

    Cool movenext & moveprevious issue

    I have a highly puzzling issue with a VB Classic application. For certain users only of a particular applications, the movenext method of the ADODB recordset object always moves to an eof condition on the forth execution. The issue occurs in 2 distinct forms where the record set is being displayed in an ms flex grid. In both problem instances, the record sets are from an MS Sql Server table.
    All users of the application are running the exact same executable off a network drive. But for some, the entire record set is displayed, for others, only the first 3 records. I've placed debug code to retrieve the recordset count property and can see that the correct record count is being retrieved. I've also run the process in debug on one of the problematic work stations and i can literally see the .eof condition being set prematurely for the record set.
    I've tried a work-station specific install of the application. I've also had the users' odbc sql server drive and the MSADO26.TLB upgraded on these PCS, all to no effect. The PC operating system does not vary for the problem group. The record scrolling and flex grid display are done within a do loop (do until rs.eof).
    Can anybody offer any advice (or magic bullets) for diagnosing and fixing this problem? Is there some .dll, .ocx or .tlb file which might be out of date or out of sync on the PCs with this issue?
    Oh yes, I've also tried a reverse read of the record set, starting with a .movelast method and iteratively using the .moveprevious method until the BOF condition is reached. The process does not stop after 3 records; it does not stop at all, but continues to extract records until the capacity of the flex grid (32,767) is exceeded.

  2. #2
    Join Date
    Apr 2007
    Location
    Sterling Heights, Michigan
    Posts
    8,663
    Welcome to DevX

    Lord, I just love these type of problems (NOT! )

    Can you detect any type (and I mean ANY type) of consistencies in the group of users that are experencing this problem?

  3. #3
    Join Date
    Feb 2008
    Posts
    6
    No, while some have different versions of Windows NT Professional, the problem does not follow these differences. Some of the problem PCs have the same version as I (who do not experience the issue). Others do not.
    I feel that I've eliminated the ODBC Driver and the MSADO26.DLL as issues; the problem persists with programs compiled with msado27 & msado28.
    I've also checked the .ocx file relating to ms flex grid.
    Can you think of any other specific support file which might be an issue?

  4. #4
    Join Date
    Apr 2007
    Location
    Sterling Heights, Michigan
    Posts
    8,663
    What about the network workstation connection and how the machine is communicating with the database?

  5. #5
    Join Date
    Feb 2008
    Posts
    6
    All of the users, problematic and otherwise, have the same network connection. But the problem does seem to relate to the actual workstation. If I log in to one of the problem PCs using my own nt password, I experience the same symptoms.

  6. #6
    Join Date
    Apr 2007
    Location
    Sterling Heights, Michigan
    Posts
    8,663
    Quote Originally Posted by dman
    All of the users, problematic and otherwise, have the same network connection. But the problem does seem to relate to the actual workstation. If I log in to one of the problem PCs using my own nt password, I experience the same symptoms.
    Now we are getting somewhere dman.

    The next thing I would check would be:

    workstation jacks
    workstation cables
    workstation NIC cards

    My thought being a potential degraded signal between the workstation and the network/database.

  7. #7
    Join Date
    Feb 2008
    Posts
    6
    Hack, I can ask desk top support to check these things. The 3 known problem pcs are all in the same row of cubicles. I'm going to try the following:
    1. have one of the users, move their pc to a different docking station, mine for instance and see if the problem persists.
    2. assuming no resolution, have desk top support check all of the items you cite at one or more of the workstations.
    3. if none of the above work, punt.

  8. #8
    Join Date
    Apr 2007
    Location
    Sterling Heights, Michigan
    Posts
    8,663
    Sounds like a plan to me.

    PS: I'll hold the ball while you kick it.....I promise not to whisk it away at the last minute *looks around and whistles*

  9. #9
    Join Date
    Jan 2008
    Posts
    19
    I have had this movenext, EOF... problem where you only get a few rows back when there are actually more rows.

    My suggestion is that you look into the cursortype of the recordset you are using, it makes a big difference in what records you get back.
    With a combination of a "Do while not rs.EOF......Loop " might just get you all the records you need to get back.

    GoodLuck

  10. #10
    Join Date
    Apr 2007
    Location
    Sterling Heights, Michigan
    Posts
    8,663
    Quote Originally Posted by Bode
    I have had this movenext, EOF... problem where you only get a few rows back when there are actually more rows.

    My suggestion is that you look into the cursortype of the recordset you are using, it makes a big difference in what records you get back.
    With a combination of a "Do while not rs.EOF......Loop " might just get you all the records you need to get back.

    GoodLuck
    This is a good point, but, if this was the issue, it would be happening on all machines, not just a few.

  11. #11
    Join Date
    Feb 2008
    Posts
    6
    Good morning,
    Hack, I tried your diagnostic suggestion, connected my laptop into the docking station at one of the problem sites. And the issue went away. In displaying the contents of a fairly large record set, all 16000+ rows were displayed in the grid. This tells me that the issue relates to the PC itself, not any of the external hardware used to connect.
    I spoke to our desktop support people about checking the NIC card. They informed me that the docking stations have their own NIC card, which reduces the chances that the card is at fault.
    Bode, I appreciate the suggestion. But it appears that all the records are being retrieved by recordset.open statement; I placed a diagnositic statement, x=rsGeneric.recordsetcount statement in the code and x was set to the correct value. But regardless of the count value, when the rs.movenext statement is executed for the 4th time, the rs.eof condition is set to TRUE.
    Hack, since the users are connecting to the network via a docking station with its own NIC card, is it worthwhile to check the NIC card in the PC?
    To all, I can't help thinking this problem relates to one or more of the support files which are not explicitly part of the executable, but I've checked and/or updated all the ones obvious to me (msado26.tlb, msflxGrid.ocx, Microsoft SQL Server ODBC Driver). Can anybody suggest any others I've missed?

  12. #12
    Join Date
    Apr 2007
    Location
    Sterling Heights, Michigan
    Posts
    8,663
    Well, I'm thinking just the opposite and instead of software related (such as support files) I'm still leaning toward hardware related.

    Do you have docking stations on hand? If so, swap one of these docking stations out, just as a test, and see what happens.

  13. #13
    Join Date
    Feb 2008
    Posts
    6
    In effect, I have swapped the docking station, by plugging my own, non-problematic PC, into the docking station of one of users experiencing the problem. If the docking station were at fault, then I would expect to experience the same partial displays on my PC when running the application in question; I did not.
    Doesn't this point to a strictly PC-related issue, either software or hardware?

  14. #14
    Join Date
    Apr 2007
    Location
    Sterling Heights, Michigan
    Posts
    8,663
    Quote Originally Posted by dman
    Doesn't this point to a strictly PC-related issue, either software or hardware?
    Yes...it does.

    I'm still not sold on the software part, but I'm flexible.

    What support file differences do you see?

Similar Threads

  1. Deadlock issue in SQL Server
    By manumishra in forum Database
    Replies: 5
    Last Post: 06-09-2008, 04:28 PM
  2. Replies: 1
    Last Post: 07-18-2007, 09:34 AM
  3. They created J#, why couldn't they do VB#?
    By Thomas Eyde in forum .NET
    Replies: 290
    Last Post: 12-22-2001, 03:13 PM
  4. Replies: 0
    Last Post: 09-19-2001, 06:48 AM
  5. Movenext Error
    By Martin in forum VB Classic
    Replies: 1
    Last Post: 01-19-2001, 11:41 AM

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