"Fatal Error -36 reading row" : We started getting this error in our applications when a table has both a quickdex and btree indexes on it. Don't know when it started, but we found out about it when a user tried to do a list statement with a "by" field that has both a btree and a quickdex. Ex: "list container_data by container". If I take off the quickdex or put it before the SI.MFS, then the list statement works. However, I believe the rule is SI.MFS should be last in the order. Is this correct or does it really matter?

We are using arev3.12 and have been for years. Microsoft windows 2000 advanced server, service pack 4; linear hash NT service ver 1.5.0.0. No major changes except for all the microsoft patches etc.. that we always get.

We use the quickdex for popups, and we have a work around obviously if we take the quickdex off, but I would still kind of like to know what's going on. Anybody have any ideas?

' .. If I take off the quickdex or put it before the SI.MFS, then the list statement works. However, I believe the rule is SI.MFS should be last in the order. Is this correct or does it really matter? .. '

hmmm .. it should be quickdex then MFS ..

but that is what you are saying you do to correct it

does Slack let you play up here?

dsig

only when he's gone. Oops, I mean it works if I put the quickdex after the SI.MFS. So have you seen this error, and does it "really" matter if the quickdex comes before or after the SI.MFS?

To answer the question, just think about what each does. SI.MFS interrupts calls and maintains information on a different file, the ! file associated with the data file. Quickdex, on the other hand, maintains its data in a record called %RECORDS% stored on the data file.

If Quickdex is first, then SI.MFS has to process (index it like a data record) %RECORDS% unless it does a direct BFS call instead of calling the rest of the MFS list. I don't recall which way Quickdex works. If SI.MFS was first, then it never sees %RECORDS%. Only Quickdex does, so it won't be indexed. From this perspective, it makes more since to hav SI.MFS first.

On the other hand, one primary purpose of Quickdex is to interrupt select processing. Instead of actually doing a select on the file, it returns the list based upon the contents of %RECORDS%. If Quickdex comes after SI.MFS, though, SI.MFS does its select processing first. If your select statement selects on an indexed field, SI.MFS will use the index to resolve the list, and I don't think it will continue to Quickdex. Which order is preferable here depends upon how you want selects to behave, I suppose.

I don't know if I've ever had occasion to use both SI.MFS and Quickdex on the same file, so I'm curious to see what more knowledgeable people have to say about this.

Victor

Nice analysis Victor,

if I interpret it well, it means … having both SI.MFS and quickdex.MFS on a table has no sense.

… I fight against quickdex.MFS … SI.MFS is much more universal, and almost as fast as quickdex in the case when quickdex is working.

Yes, there is an additional !table, but having index info separated prevents data corruption (or prevents data loss … just cleartable !table and recreate indexes).

Thanks all of you for your input. They had the quickdex on the table for use in a window to do quick f2 search, but we can do a select with btree just as easily, so I agree that you don't need both, but I am still interested to know why it work for 10 years, and now all of a sudden it comes up with an error. Oh well, just one of those mysteries you never get the answer for.

Just a thought… maybe the quickdex was erroneous for some reason, having a reference to a record that didn't exist. Changing the order of the MFSs, depending upon how you did it, could have re-initialized the quickdex with the correct information. Simply removing it and reinstalling it into the same position would have, too. I wonder if that would have solved your problem just as well…

Victor

View this thread on the forum...