none
Index tag is corrupted - NOT. RRS feed

  • Question

  • I have a customer with a setup of windows 10 stations on a win2012 server.

    Once in a while a user will get the "index tag is corrupted" error message, but it cannot be the case because many users use that same tag and that same user can just log back in and use the same tag.

    I was thinking this may be caused by some sort of a network interruption.

    Anyone experienced this? Any suggestions?

    Thanks!

    Monday, May 6, 2019 3:20 PM

Answers

  • Again and in very short: Your index might be corrupt just for one seek value. Not all corruptions of DBF or FPT or CDX file show immediately after USE, reading a memo field or at SET ORDER. And other seeks even on the same tag can work.

    I'd still check the data with the procedure I outlined. It's easy enough to do and if the data files turn out to be fully healthy (you can seek every value and find it) then you can say you know its a network problem. Up to now you can only say - as you do - you think its probably a network issue.

    You can know more, so why don't you go for it? All you need is a copy of the database as is and a check routine as outlined.

    Don't know how to check a tag the way outlined? You best know the indexed fields or expressions. If you have the line of error you know which tag in which table failed and you can concentrate on that:

    Select Distinct thefield As seekvalue From thetable Into Cursor crsSeekme
    Scan
       If Indexseek(crsSeekme.seekvalue,.T.,"thetable","thetagname")
          If Not (seekvalue==thefield)
             Messagebox("there's a mismatch in the index finding "+Transform(thefield)+"instead of "+Transform(seekvalue))
          Endif
       Else
          Messagebox("there's a problem in the index finding "+Transform(seekvalue))
       Endif
    Endscan

    And you can generalize this to go through all index tags and all index espressions.

    Don't be satisifed by the fact the app works with the next login again and use the same table and tag, as long as people don't touch the corrupt index node the tag can work, just like a single broken memo doesn't mean the table can't be used anymore.

    The likelyhoood you have an index corruption when an index corruption is reported is very high and there are still all the "traditional" possible corruptions, which can occur in files, no matter what OS.

    In a way it's nice people only experience reccount header corruptions VFP is unfrotunately famous for or total crasshes of files you can blame on network/oplocks. But there still are all kind of file corruptions tools like foxfix also know to fix.

    Bye, Olaf.

    PS: Your index tag is intact, if no messagebox is displayed and no error is thrown by the indexseek calls. Furthermore a helpful function to get all tag info is ATAGINFO().
    • Edited by OlafDoschke Thursday, May 9, 2019 7:39 AM
    • Marked as answer by Aleniko2 Wednesday, May 15, 2019 2:22 PM
    Thursday, May 9, 2019 7:14 AM

All replies

  • Windows 10 has intermittent map drive. Took me a while to find that out 

    Copy your executable into a local C, and run it from there.

    Tuesday, May 7, 2019 12:46 AM
    Moderator
  • Benny Thanks for your input. Can you elaborate? I don't see why would that generate corrupted index and not corrupted databases and tables?

    Also, even if I run the executable from c:, All my  data files would still be on the server.

    Thanks!

    Tuesday, May 7, 2019 2:58 AM
  • Hi Aleniko2,

    to be honest.... IMHO for a long time it hasn't be a good idea anymore, to use VFP DBs/Tables via network. Microsoft has be changing their ways of accessing network drives more and more that VFP can't keep its data correctly anymore.

    There are i.e. two ways do react on this.

    #1

    make the customers 2k18 Server a terminal server and let the users access it via remote desktop (RDP) and install your application that way that its placed on the server with all its data and the users start the application within their RDP session.

    #2 (mostly nonusable because of the time that may have to be invested)

    make the switch to a modern database and use ODBC to access your data that's then stored in SQL Server, PostgreSQL, MySQL, MariaDB, Oracle, Informix or or or.

    JM2C ;)


    Gruss / Best regards
    -Tom
    Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible,
    you are, by definition, not smart enough to debug it. 010101100100011001010000011110000101001001101111011000110110101101110011

    Tuesday, May 7, 2019 12:49 PM
    Moderator
  • Tom;

    If that was the case, my very large application won'y be able to survive. Yet, I see little problems here and there which are just nuisance.

    I have a feeling the index corruption (And yet never table corruption) is related to something else.

    Alen.

    Tuesday, May 7, 2019 3:16 PM
  • Could it be that a network issue is making it look like there's index corruption? That is, that the error message isn't accurate because someone about a network issue makes it look like index corruption to VFP?

    Tamar

    Tuesday, May 7, 2019 8:33 PM
    Moderator
  • The only CDX corruptions I had regularly were due to oplocks.

    I had rare other occasions really just file corruptions. and they had the nature of only failing on one value seeked.

    I did a test routine reading in all the unique values of a field SELECT DISTINCT field FROM table INTO CURSOR crsSeekme and then SEEKed all these values and only some were not found or caused an error.

    As you said the same user use the same index tag again after restarting,it's a corruption of that kind, most likely. It's still a corruption. Just like a wrong Memo or a single blanked record are corruptions that also can occur in FXP and DBF files, a CDX tag might only be corrupt in one node, but then it will repeatedly trigger an error to seek a specific value.

    Maybe Tamar also hits the point with a network issue looking like a CDX corruption.

    But errors are not all like "... is not a table". Even that most often is just about the 4 bytes having the reccount in the DBF header and conflicting with the file size. But just SET ORDER TO TAG x doesn't have any such tag check or BROWSEing a table with a corrupt memo value also only errors when you then scroll to the corrupt record.

    the SET VALIDATE level does a few tests, but none of them chacks a whole table, all tags or just even one tag, the runtime would need to go through all a file, tag or such.

    So to see, if your file really has no corruption and this is just a glitch in a network package not containing what should and will next time be read from a file block can be checked.

    The simple rule about a CDX tag is, you seek all the values from the dbf (or when you indexed expressions seek all those expression results, of course) and check whether the field actually has the value you seeked for. Typically that's what you take for granted, but there can be errors in the index tree structure causing to look for a file block not existing and there can be errors that only point to the wrong recno at a index tree leaf and you only can rule out all these errors with a thorough check of finding all values possible to find with the data at hand.

    When you prepare the list of seek values forom a sql SELECT query SET OPTIMIZE OFF to simply read all values from DBF/FPT without using the CDX first, then SEEK all of them and see if you a) get no error thrown and b) get to the correct record by actually reevaluating the index expression at the found record and see if it matches exactly what you seeked.

    Bye, Olaf.

    • Edited by OlafDoschke Wednesday, May 8, 2019 11:28 AM
    Tuesday, May 7, 2019 9:01 PM
  • Tamar; That's what I was thinking. Because it happens rarely, and I do nothing to fix it - the user just logs back in and all is good.

    Wednesday, May 8, 2019 8:17 PM
  • Olaf;

    As always thanks for the detailed response. I think its probably a network issue.


    Wednesday, May 8, 2019 8:18 PM
  • Aleniko,

    This is the article I found. Hope will be helpful

    https://www.experts-exchange.com/questions/29113740/VFP9-Lost-Conecction-with-MSSQL.html

    Wednesday, May 8, 2019 11:41 PM
    Moderator
  • Again and in very short: Your index might be corrupt just for one seek value. Not all corruptions of DBF or FPT or CDX file show immediately after USE, reading a memo field or at SET ORDER. And other seeks even on the same tag can work.

    I'd still check the data with the procedure I outlined. It's easy enough to do and if the data files turn out to be fully healthy (you can seek every value and find it) then you can say you know its a network problem. Up to now you can only say - as you do - you think its probably a network issue.

    You can know more, so why don't you go for it? All you need is a copy of the database as is and a check routine as outlined.

    Don't know how to check a tag the way outlined? You best know the indexed fields or expressions. If you have the line of error you know which tag in which table failed and you can concentrate on that:

    Select Distinct thefield As seekvalue From thetable Into Cursor crsSeekme
    Scan
       If Indexseek(crsSeekme.seekvalue,.T.,"thetable","thetagname")
          If Not (seekvalue==thefield)
             Messagebox("there's a mismatch in the index finding "+Transform(thefield)+"instead of "+Transform(seekvalue))
          Endif
       Else
          Messagebox("there's a problem in the index finding "+Transform(seekvalue))
       Endif
    Endscan

    And you can generalize this to go through all index tags and all index espressions.

    Don't be satisifed by the fact the app works with the next login again and use the same table and tag, as long as people don't touch the corrupt index node the tag can work, just like a single broken memo doesn't mean the table can't be used anymore.

    The likelyhoood you have an index corruption when an index corruption is reported is very high and there are still all the "traditional" possible corruptions, which can occur in files, no matter what OS.

    In a way it's nice people only experience reccount header corruptions VFP is unfrotunately famous for or total crasshes of files you can blame on network/oplocks. But there still are all kind of file corruptions tools like foxfix also know to fix.

    Bye, Olaf.

    PS: Your index tag is intact, if no messagebox is displayed and no error is thrown by the indexseek calls. Furthermore a helpful function to get all tag info is ATAGINFO().
    • Edited by OlafDoschke Thursday, May 9, 2019 7:39 AM
    • Marked as answer by Aleniko2 Wednesday, May 15, 2019 2:22 PM
    Thursday, May 9, 2019 7:14 AM