Michael B. Brutman wrote: > I don't think you have a networking problem; I think it is a > hardware problem, or very bad device driver settings.
Could you give any hints on the "device driver settings" part? > "General failure reading drive C" is a bad sign. I would make a > new backup of that server hard drive (do not overwrite an > existing backup in case the backup fails mid-way). Yes, we backup often. It's the data of 15,000 patients currently, due to grow to 30,000! But don't be too concerned about the "General failure reading drive C": we have been using the same machine as standalone, and it works perfectly as long as it is not networked. Besides, during testing we tried different hard disks, NICs and whole boxes, including my own at home (the one I'm now writing on), which reproduced the exact same problem when networked, and otherwise works just fine. > What OS are you running? [..] You can do better with a current > (or recent, but not new) Linux running with a text console [..] > and Linux is robust and easier to diagnose when hardware or > software is misbehaving. I'm running FreeDOS, but yes, Linux is a possibility. This database project started modestly in 2006, but now the Health Center is relying more and more on it, so I want it to be very safe. Still I would definitely prefer to stay with FreeDOS if at all possible :-) It would be much simpler for me too -- I do this as voluntary work and don't earn anything for it. > If you have Pentium gear you probably have 100Mb/sec hardware, > so that number is closer to 10 times more. Are your clients > accessing this database really generating 1MB or more of data > per second? I understand the NIC is 100Mb/sec, and Yes, the load must be quite low. The current *total* file size of all database tables is just 4.4 MB. -------------------------------------- Eric Auer wrote: > Did you try using only UIDE or only LBACache for > caching? I used UIDE *or* LBACache, not both simultaneously. > If you use UIDE, did you try "BIOS mode" so it only caches but > does not provide UDMA I/O? I'll try that. > And have you tried using higher STACKS settings? > As far as I remember, LBACache also had an option > to provide more stack - but I probably made that > the default and removed the option? Read docs ;-) I did, by changing it in fdconfig.sys. I usually have stacks=0,0, and I tried with other values such as stacks=16,256. > Note that there are multiple free versions of SHARE, > possibly involving Tom and/or Japheth. I think there > is a version with improved compatibility with s.th. > on Japheth's homepage, for example? But it probably > is a good idea to use SHARE in general, if it works? I downloaded SHARE from Japheth's site, and it turned out to be the same file I had. Where could I find other versions? I Couldn't find it by searching the internet, perhaps because 'share' is too common a word. -------------------------------------- Ralf A. Quint wrote: > What I remember and at least the available DP manuals also state is > that DP is using the very basic DOS "(un)lock file region" call of > DOS 3.0+ to allow concurrent access to the same database on a > network. That would be specifically INT21h/AH=5Ch, and that call > needs to be properly supported in FreeDOS to begin with. I suppose that would involve changing SHARE or the kernel. > Any file caching software should not touch access to networked drives > (on the clients) and on the local machine that acts as server, it > needs to be aware of the locking call and act accordingly... I'll do a test with no caching in server and client. -------------------------------------- Thanks for the support! Marcos Marcos Fávero Florence de Barros Campinas, Brazil ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
