Invalid SEEK offset 1

[AndrewMozley]

I have a client who has been running a VFP9 application across a network for several years. He has sent a screenshot of an error ‘ Invalid Seek Offset’, at the time when he had entered an account code, and the application should have been doing several things, including executing a SEEK in his customer table (about 2MB).

I understand that this has happened before - but presumably not often enough to make the application unusable! I have not been able to reproduce the error either on my development system or when logged in remotely to the client’s network.

The application does have an error routine (“ON ERROR . . .”) which notifies the user and writes details of the current state, line number of the error &c to an Errorlog.txt file. But in this case nothing is being written to this log file.

I can certainly re-index the tables, in case that helps. But would be grateful to know of other user’s experience of this error, and any other actions I can take.

Thanks. Andrew M.

 

[Mike Gagnon]

http://wiki-209232.usedtech.org/visual-foxpro-invalid-seek-offset-error.html

If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[Dan Olsson]

Mike, is that something you recommend?

I find it somewhat suspicious when a page have several links to the same download AND when you tries to leave the page it even shows a dialog that is meant to look like an UAC prompt with ANOTHER link to the download.

Also in my experience this error never comes from registry errors or such, only from bad networks or indices.

/Dan

 

[AndrewMozley]

Thank you for your contribution Mike; but also thank you Dan. I am wary of undocumented links, but when I saw your note I thought I would investigate. The screen went dark when I tried to navigate down to see whether the link had an answer to my question; it offered to download a trial version of a software package; it didn’t say what the price was, or much detail of its functionality.

Perhaps foolishly I clicked on that pop-up, but my anti-virus warned me that it contained a potentially unsafe program. Took its advice and left.

In the matter of this ‘INVALID SEEK’ error, does this error come from VFP9 itself? and is there any way of trapping it so that a customised message can be shown to the user - and maybe recovery code executed by the application.

It would be good to know if other users have come across this problem and how they have coped with it.

Thanks again.

 

[Mike Lewis]

Andrew, I have heard of other people having this error. On at least one occasion, it was traced to some corruption somewhere in the database (either the DBF, CDX or FPT). I can't remember the details, but I know that it was solved by recreating the database. To be exact, they recreated the DBFs from scratch, appended all the data from the old DBFs, then rebuilt the indexes. That solved the problem.

Of course, I can't guarantee the same solution would work in this case. But keep it in mind.

Also, as far as I am aware, this error message is not necessarily specifically related to VFP's SEEK command. I think it refers to a lower-level "seek" within the operating system. The fact that it does not trigger VFP's error-handler seems to confirm that.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Gagnon]

Dan & Andrew

Sorry for the bad link. In any case I agree with Mike, in my experience invalid seek, is either corruption of an index or I/O error.




If you want to get the best response to a question, please check out FAQ184-2483 first.

 

[Olaf Doschke]

You say nothing has been written to your errorlog.txt. If your errorlog.txt is on a file share you have your answer why this wasn't logged there: It's pointing out a network problem.

Just because the word seek appears in the message it's not necessarily about indexes and the seek command or function. I've seen this reported for anything network related, as it's likely more about FSEEK, accessing a file beyond its size. And not necessarily really that but by false information about that file size - because of network errors.


The error message was popping up to users, didn't it? So you already know it arrived in your error handling, it just didn't save and if that is on the network share along with the dbfs, there you have it.

So for now, you should change your error handler to mainly store error info locally on a local drive and then collect it centrally in a file on a share. For example, you could append the local TXT (or maybe a DBF in the future) to a central file at application start and then empty the local file (After ensuring this appending worked).

And also, for now, you could already inform your customer if this happens regularly it would be good to let a network expert look into this in more detail and monitor the network. Especially, if also future error handling doesn't point out which code is causing this but it happens "randomly" with just one common denominator: Access to a network share.

One pro tip about collecting error information locally: Don't spare a datetime, because the "appending to central log"-business of course means you don't get errors in chronological order and can't easily see time correlation which may not prove but indicate causality, eg:

1. two clients have problems at the same time with the same file: Likely that file is corrupt.
2. two clients have problems at the same time with different files of the same share: Likely the network is problematic.

For that reason knowing the time of errors is important and you can only correlate errors if you can see when errors happened and sort by that time.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name

 

[AndrewMozley]

Thanks Mike L.

I take your point that the error message (not sure from where) may not necessarily indicate a SEEK problem - although that is the main think the application had been doing.

I get the impression that the error is very occasional. I will develop a utility to rebuild all the tables in the database (do you by chance have one?) and give the user the option to run it after close-of-play, from time to time - just in case that is the cause of the error.

I will also suggest that my client ask his network support person to run tests - just in case that points to the source of the problem.

Andrew M.

 

[Mike Lewis]

(do you by chance have one?)

'Fraid not. But if you develop one yourself, you should be able to make it completely generic, so it could be of benefit others.

give the user the option to run it after close-of-play, from time to time

If my theory is correct (and I am not insisting that it is), it should only be necessary to run it once, at the point that the error message occurs. That should get rid of the corruption once and for all (unless it does turn out to be a recurring network error, of course).

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

From my experience with several applications ranging from a small slow network and few users, with a large network and about 500 users I had corruptions, also repeatedly and obviously caused by oplocks, but I never had error 1103, Of course, FSEEK also is an operation done when VFP SEEKS a value in an index. It's not a random coincidence that command is named that way, but index errors more often cause error 2066, not 1103.

And I told more than once to prevent errors a preventive reindexing of all data was done every night with Stonefield database toolkit repair functionality, which you cannot only apply to corrupt tables or indexes. Alone reindexing, of course, helps, as a clean index isn't cluttered and doesn't get that cluttered or bloated within a single day.

Anyway, in detail about that error, I'd not be too sure this is all you need to do, because as said I never had that error. If you log errors as I suggested you may see that it happens not just at seeking, but at starting forms, opening tables, whenever network access is, and in that case, it's likely possible to stabilize the network. Because as said twice already, I did never have that error and the companies I worked for had network admins caring for the network hardware. The small slow network wasn't slow because of hardware problems but simply a budget decision, for example. So you can have networks free of that error, there are still enough other intrinsic problems, but this isn't one that's unavoidable from my perspective and experience.

We had repeated problems especially in the larger network, naturally. I still think too many people had too many rights and too many time to define routes with the DOS shell, because often we had MSSQL connection problems and it turned out TCP/IP packets ran in routing loops because someone may have managed to add a local network printer, but at the same time rerouted a lot of network traffic. If you do that wrong packets die after their TTL (time to live) counter goes to zero.

And not just my software was affected in other cases, where there really were network outages, switch and router outages.

But network administration and configuration isn't really your job, but you can at least find out more if you enhance your error logging.

Bye, Olaf.

Olaf Doschke Software Engineering

https://www.doschke.name