Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Error 1103 Illegal Seek Offset

Status
Not open for further replies.

generlam

Programmer
Jun 13, 2001
75
US
My users are sporadically getting error 1103 when doing a seek on several tables. This does not happen all the time and it doesn't happen to everyone.
We are running a Foxpro executable on a Novel Network. Most users have Windows 95 at the moment, but a few have Win2K and access the executable through Citrix.
Has anyone had any experience with this error?
 
I used to battle this error all the time. In my case it was a contaminated CDX/DBF headers because of the differences in MicroSoft/Novell File Allocation Tables on Hard Drives.

Microsoft addes information to the header of files when created on a NT/W2K High Performance File Allocation Tables (FAT) and them "Moved" to a Novell FAT or 16 bit Microsoft Fat. These FATS can not read the 32 bit information Microsoft places in the headers.

To solve the problem I stopped using the DOS/Win copy command with DBF & CDX files. Instead I used the FoxPro copy command. FoxPro copy will create a header on the FAT it is creating the file on so there are no additional info in the headers to cause a problem.

Hope this helps you. David W. Grewe
Dave@internationalbid.com
 
Thanks, but the users don't create any dbf's on the network. They will update, add and delete, that's it. It has to be something else.
 
Our network operations team finally figured it out. It seems that the Network Interface Card, 'NIC', for the Novell server on which the tables reside was the culprit. They replaced the driver, I'm not sure if it was corrupt or whether they needed to update, but as soon as they did, we had no more 1103's.
 
I saw this problem when accessing data across a wan. It seemed to appear after we gave the users new faster computers. We thought it was possible that the pc were going faster than the wan devices. I wrote a little "wait a second" proc that would run prior to doing the seek. It seemed to eliminate the problem.

FWIW - Wayne
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top