Mixing XP, Win2K and Win9x Workstations 2

[dataccount]

I know this is an old problem, but for me a solution has never been found. My FPW26a applications run flawlessly on Win9x peer-to-peer networks (server and workstations all running Win9x). But, put a Win2K or XP machine on the network and it will get one of two error messages - error 15 "Not a table/DBF" or error 41 "MEMO file is missing/invalid", and be kicked out of the application. Meanwhile, the Win9x machines sail along as though nothing happened.

Several possible fixes have been tried including creating and storing the application tables on a FAT16 partition, adding the line "MEMLIMIT = 60, 2048, 16384" to the config.fpw file and even doing a "Functional" conversion to VFP6. Users on the XP or Win2K machine still get one of these error messages about 90% of the time when opening a table shared with Win9x users. The network protocol used is TCP/IP.

Until now my solution has been to tell the client either to stick with Win9x on all machines or go entirely to XP/Win2K. Frankly, some clients resent being told what operating system they must use, and blame me!

I would surrender my firstborn for a solution to this problem. Thanks.

Jim B.

 

[tondi]

I occasionally have that problem. I did so much more often when the 'data server' was XP or Win2k. By changing the 'data server' to a Win9X or even DOS computer while using XP or Win2K workstations, the problem seemed to go away. I have several users still using POS terminals with IBM Dos 7.0 and Lantastic NOS.

Occasional 'error 15' will happen regardless of OS or environment due to other variables.

good luck..no need to give up the child

Tony

 

[dataccount]

Thanks Tony,

You probably saved me even more grief, because my next thought was making one of the XP-Pro machines the "data server". Sounds like that would be a mistake.

I still have an old copy of PC-DOS around somewhere, so maybe that's worth a shot. Hey, I'm desperate. It does appear the problem centers around the FAT, and if I remember correctly, when I was experimenting with placing the data files on a FAT16 partition on the server, the operating system on that server was Win98, installed on a FAT32 partition. Monday I'm going to convert the operating system partition to FAT16 as well, and leave the rest of the drive unallocated.

If this works, I'll post it in case anyone else has this problem.

Jim B.

 

[dataccount]

That didn't work either. I have a small client with 12 workstations that I changed the c:\ drive partition to FAT16 - the rest of the drive is unallocated. Both the Win98 operating system and my FPW26a application reside on this partition.

This morning after a single user on a Win98 workstation appended a record to a table having a memo field, the lone XP workstation could no longer enter this module in the application. Error 15 was generated on the code line opening the table.

I should mention that after changing the server drive to FAT16, I ran a program from the server that removes all index tags and re-creates the index on each table.

Back to square one.

Jim B.

 

[DARKKESTREL]

I had some similar problems with an application that used a W2k as a server and the problem IS the filesystem in which the FoxPro files resided.

In my scheme the thig worked when I patched the FoxPro (don't remember the patch, but is the one that fixes it in 2000 / XP) and made it take the files in a FAT32 partition beacuse the FAT16 support seems to be limited.

 

[zucaro]

I have a very similar problem. My server is a Win98 machine. My lone xp workstation is my laptop and it seems to me that the problem resides with the way that XP is caching the data. I often get this error "Not a table/DBF" first thing...then if I do nothing except leave thing alone for 10 minutes and try it again it works fine. This seems to indicate to me that foxpro is unable to handle the way that XP is presenting the table to it. I can open the very same file at the same time from another Win98 workstationand the table is ok.
Is this what you are seeing?

 

[dataccount]

Yes, Zucaro that is exactly what I am seeing. The problem only occurs after a new record has been added to the table, and goes away in a few minutes if no one adds another record.

Up until now I have been focusing on FAT as the cause, but I thing Rick (rgbean) was right on the money when he explained in Thread182-396180 that the problem was caching. It makes sense that after a few minutes XP can access the table, because by then the new record has been written to the disk. Don't know why it's a problem with XP/Win2K and not Win9x.

That said, how can it be fixed? I already have Autosave set to "On", which is supposed to flush the data buffers to disk when you exit a READ. Would it help to insert the FLUSH command after a new record is added? I'm gonna try that tomorrow. If I knew how to disable write caching on the Win98 server, I would do that too, but I don't.

Jim B.

 

[DSummZZZ]

Allow me to paste my response from another thread:

I don't think you are going to be able to use any OS newer than '98 to access a table on a '98 box. NT, XP or whatever.
Chances are real good that your workstation won't recognize file or record locks on a '98 machine, not to mention whatever buffering '98 may do may not be updated properly in time for NT to read.
Were you hosting the files on a Win 2K server, or maybe even workstation, you would be able to do it.


With that said, you should be able to host the files on a XP box as well as a Win 2K box. But you may have to figure out how to shut off the 'Write Cache' in order for all other workstations to "see" updates to the tables.
No guarantees, and do this at your own risk, but here's how to shut of write caching:
Using NT, I went From the control panel to 'Administrative Tools'->Computer Management->Storage->Disk Management.
Right click on the volume you want to change (C:\), and select 'Properties'. Click the 'Hardware' tab, and select the hard drive. Click 'Properties' then 'Disk Properties'. Click the box labeled 'Write cache enabled' to DEselect it. Click 'Ok' etc., to close all the windows. You may need to reboot.



Dave S.

 

[dataccount]

Dave S.

Thanks for your input. I'm sorry I didn't see your original post on the subject - that sure would have saved a lot of aggravation during the last couple of years.

Jim B.

 

[jonesson]

tondi seemed to indicate that putting a Win2k in as a server caused more problems. I'd be very interested in knowing if the 2k server solves the problem and if all the 98 nodes still have good access.

 

[dataccount]

Today I took a brand new Gateway with XP/Pro installed and set it up as the data server on a Windows peer-to-peer network. Everything went fine until the 11th user tried to log on. I didn't know XP had the same 10-user limit that Win2K/Pro has. This mixture of Win98 and XP machines worked the FPW26a application in total harmony, appending and editing at will.

Surprisingly, I did not have to disable write caching on the server, nor did I have to change the XP file system from NTFS. I didn't think Win9x machines with FAT32 partitions could write to NTFS partitions.

Now I feel confident in giving clients a choice - if they have 10 or fewer computers running mixed operating systems, make sure an XP/Pro (or perhaps a Win2K/Pro) machine is the server. With more than 10 units the only choice seems to be Win2K (or Win2003) server.

Jim B.

 

[DSummZZZ]

I didn't think Win9x machines with FAT32 partitions could write to NTFS partitions.

It isn't really the '98 box writing to the NTFS partition. All they really do is send data to the NT/XP 'server' and ask that the data be written. The NT/XP OS takes over from there and writes to the partition.
That's my reasoning behind mixed OS's not recognizing different OS's file locks properly, at least without some sort of network client software being updated.


Dave S.