Error Message: Page number too big. Make sure ALL index files are updated

[cyberspun]

Hi,

I keep getting this message and I am not sure what it means? Any one else ever see this?

Thanks!

Allen

[David]

The "page number too big" error is a typical result of a corrupted or inconsistent set of index files. This might happen if

1. You only uploaded half the files to your server
2. You uploaded the files in FTP ASCII mode rather than Binary mode. This can only happen with 3rd party FTP software. Not with the built in FTP function.
3. You have some files from V4 of the software and some from V5. e.g. the V4 search script with a V5 set of index files.
4. You have some files from an old index session and some from a new indexing session all mixed up.
5. There is a disk error on the server and the files are corrupted.

The solution is typically to delete the set of files on the server and re-index.

[cyberspun]

Thank You! The new indexing fixed the problem

[jessimckinnon]

I'm having the same problem. I never had version 4 installed previously, and everything was working perfectly as the free version. This problem started after I entered my license key and reindexed the site (from scratch, without using the cache) to index all the files beyond the free limitation. There is no FTP'ing involved as I have direct access to the web server's filesystem (internal test server). Even if I delete all output files (including the custom template), and there is nothing in the output folder prior to indexing, I still have the same issue.

Oh, one thing that is different between my free installation and the current one, is that I have the plugins installed (which were not available in the free version).

The solution is typically to delete the set of files on the server and re-index.

Is there anything else that could cause this error? Is there anything that I can do to provide additional debugging information? Are there any other less common solutions than the one "typically" sufficient?

Despite the error, the search results returned still seem correct.

Thanks,
Jessica

P.S. Other than this issue, I love the product. It took very little time to get everything up and running and completely integrated into the site.

[Ray]

If you are sure that your output files are from the same session, and you still experience this problem, you should zip up your output files and e-mail them to us for a closer look.

Please provide any additional information that may be helpful (whether you are using incremental indexing for example, or a full re-index). It may also help if you send us your ZCFG file containing your indexer settings.

[jessimckinnon]

As fate would have it, I got back to it this morning after the weekend, and without having changed anything, I clicked the search button again, and the error disappeared from the search results.

Could it perhaps be that the files were cached by the web server or the ASP application cache, and it worked fine this morning, because no-one had hit the page since last Friday? If so, does the script have any undocumented actions to either clear the cache or force a reload of the newer files into the cache?

Thanks again,
Jessica

[Ray]

The ASP search script does not have any caching functionality or code.

However, it is possible that your IIS server has been configured to cache ASP pages. This can sometimes be cleared from the IIS Administration interface and unchecking "Cache ISAPI Applications" setting, clicking Apply, and then turning the setting back on (if you want it to be enabled). Refer to Microsoft's IIS documentation (it is different for various versions of IIS) for more information.

[jessimckinnon]

Ray, thanks for your input. I am very aware of how to clear things on a local site where one has access to the administrative tools. However, the live website is in a hosted environment where none of that functionality is available. Anyway, that solution would certainly work considering that the problem cleared itself after the cache timeout period had elapsed.

I think this issue can now be closed. Thanks again, Jessica.