Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Invalid Seek Offset - Network timeout
Message
Information générale
Forum:
Visual FoxPro
Catégorie:
Problèmes
Divers
Thread ID:
00364817
Message ID:
00365031
Vues:
17
>George -
>Regarding the COPY FILE MS Article that causes Invalid Seek Offset - I read it but that is not my particular problem (happens without any involvement of printing or LPT1). My question to you is, do you think it could have the same problem with COPY STRU as it does with COPY FILE? I have a program that updates local lookup tables with the network master, and after running it and then browsing the local table (c:\temp\) it often gives me the same Invalid Seek Offset message. (PS - Sorry I didn't respond directly to your message but there is some problem with the site that was precluding me)

Shawn,

No prob on the response.< s >

I quite frankly don't know if COPY STRUCTURE might produce the same problem. From both a theorhetical and abstract POV, it might. Of course, you could substitute a call to AFIELDS() and use that to create the structure, but if you're also copying the indexes, that's much more inefficient (as opposed to slightly less efficient in some cases< g >).

I've had my share of problems with Novell/Client 32. The solution that I implemented was to use the MS Client for Netware. However, I should say that I've never had a problem with a connection timing out. In fact, it's been the opposite.

Before we upgrading to Netware 4.x and increased the number of connections, some servers ran awfully close to being max'd out. Since my applications sometime have to work with data across the WAN, this was a concern. I found that using UNCs could create a problem in releasing the connection. As a result, I had to implement a series of API calls to connect and disconnect from the servers as needed.

When we switched to Netware 4.x and Client 32, I ran into another problem in running scripts. Novell insisted on mapping a drive to a particular server (even though another connection existed on my machine) at one hour intervals. The primary cause was that my F: drive wasn't mapped to the standard server for my location. I confirmed the interval, by running a timer in VFP in the background and noting when the connection was restored.

One question, however, comes to mind. You mentioned NT. Are you switching (or trying to) to NT or to Win2K and have you tested on that platform?
George

Ubi caritas et amor, deus ibi est
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform