Results 1 to 6 of 6

Thread: Vb6 VS RS.EOF=true

  1. #1

    Thread Starter
    New Member
    Join Date
    Oct 2017
    Posts
    1

    Vb6 VS RS.EOF=true

    Hello All!,

    I have an applications which runs ok, in a XP machine 32 bits in combination with Bechoff Twincat plc and the PC(IPC) is from Beckhoff.
    The application uses a acces mdb file for to save machine settings
    Recently we swapped IPC machine into a IPC in Windows 10(Enterprise 2016 LTSB) environment, 32 bits , X64 processor

    The application is made in VB6 version 9782 and we have recently changed some issues concerning colors is some text field, This new version is running in combination with the twincat plc but as soon as I want to read some machine settings from the database (mdb) in to a field then the values stays on zero but in real there are values in the database.

    After logging , I found out that for some reason the RS.EOF condition is true, while in XP it is false

    'Read dimensions
    strSQL = "Select PackDefID, LayerLength, LayerWidth From tbl_Layer " & "Where LayerID = '" & m_LayerID & "'"
    rs.Open strSQL, dbsConn, adOpenForwardOnly, adLockOptimistic

    If Not rs.EOF Then
    m_PackDefID = ValX(rs![PackDefID])

    LoadingDimension.LayerLength = ValX(rs![LayerLength])
    LoadingDimension.LayerWidth = ValX(rs![LayerWidth])
    rs.Close



    Xp is using jetengine 4.0 and framework 2.0
    win 10 is .net framwork 4.8 installed, Miacces database engine 2010

    Anyone any idea's?

    Please feel free to comment.

    If some info is missing please et me know

    Kind regards,

    Ferry

  2. #2
    PowerPoster
    Join Date
    Feb 2012
    Location
    West Virginia
    Posts
    13,623

    Re: Vb6 VS RS.EOF=true

    If you are using an mdb then you would be using Jet 4.0 even on Windows 10 and the .net framework should not make any difference at all.

    if rs.eof is true that would indicate that your query returned 0 records, which indicates there were no matching records found in the target database.
    You could add a line in there to debug.print the strsql and see exactly what it looks like after being built. YOu could then copy that line and paste it into access if possible and see if you get a result set.

  3. #3
    PowerPoster
    Join Date
    Feb 2006
    Posts
    22,501

    Re: Vb6 VS RS.EOF=true

    If the program hasn't changed and the data hasn't changed the results will not change. The only likely exception is when your code has LUA (Least-privilege User Access) bugs.


    LUA Bugs impact both file and registry access. These are things that would trigger access violation errors in a proper program marked as non-legacy. Legacy code still triggers the exceptions but appcompat intercepts the exceptions, applies virtualization to the file or registry entry, then redirects the faulty code to the virtualized copy silently.

    That might work and let legacy code limp along for many years without intervention. Or it might cause weird problems including lost or corrupted data.

    These bugs were bugs on XP and earlier as well, but far too many people just made all user accounts members of the Administrators or Power Users groups in order to produce a dumbed down Win9x-like experience. This was a big security hole and people knocked Microsoft for it mercilessly, so beginning in Vista this was paved over through UAC.

    People immediately got their panties in a bunch over that as well, so Win7 added a hack to silently handle UAC prompts in many cases. This made many na´ve users happy even though it left them less protected and in many cases virtualization became more of a hazard. Now there is often little warning, aside from mysterious "failed to run the first time, but runs 'without errors' all subsequent times" scenarios.


    I'd guess you have LUA Bugs in your code or its deployment. It probably isn't opening the MDB file that you think it is.

    No version of .Net Fumbleworks should play any role here, so I fail to see how that was worth mentioning.

    MS Access 14 ("2010") installs the ACE 12.0 Provider, but unless you have explicitly changed your program's connection strings you are probably still using the Jet 4.0 Provider that is part of Windows. Or perhaps you are using ODBC Drivers or DAO? Even so, that shouldn't matter here.


    So you haven't actually told us much that is useful at all.

    Where do you think the MDB file is (full path)? Is there one with the same name in your account's VirtualStore?

    C:\Users\account-name\AppData\Local\VirtualStore\Program Files (x86)\installed-folder\blahblah.mdb

    Note that any elevated program (for example the VB6 IDE, which always should be run elevated) will see the real file. That can be confusing because the real and virtualized copy often end up with different contents.


    But that's all wild guessing. We just don't have enough useful information.

  4. #4
    Fanatic Member
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    1,011

    Re: Vb6 VS RS.EOF=true

    Also, what else has changed on the machine or its configuration?

  5. #5
    Fanatic Member
    Join Date
    Feb 2014
    Location
    Norfolk UK (inbred)
    Posts
    1,011

    Re: Vb6 VS RS.EOF=true

    Can you revert to the old version safely?
    If you do so, does it work?

  6. #6
    PowerPoster
    Join Date
    Feb 2017
    Posts
    3,274

    Re: Vb6 VS RS.EOF=true

    Yes, I think it must be what dilettante says (most probably).
    In practice: do not place the database under Program files or any other restricted place.

Posting Permissions

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



Click Here to Expand Forum to Full Width