> We are trying to push our database past its current 70Gig maximum. On
> a test machine, we set up a machine with 3 76Gig drives, 1/2 Gig of
> memory, 1 Gig of Virtual memory. We created a database (in 112 files)
> across all this space.
> At just under 199Gig, the database dies and gives the BSoD. If I try
> to connect to it using our program (Delphi/BDE), wISQL, or Server
> Manager, I get an error message:
> I/O error for file "F:\NAVCO\DB\NAVCO99.GDB"
> Error while trying to access file
> Insufficient system resources exist to complete
> the requested service
> Navco99.gdb is not the last file in the database, but it is the last
> file with any data in it (1.4 Gig, actually).
> We had a similar (possibly the same) problem in an earlier test, at
> the same place. The Event Log indicated a possible problem with the
> disk, so we replaced it and rebuilt the database. Since it has now
> happened on two different disks, the disk seems to be an unlikely
> candidate. Could it be the controller?
> One of the frustrating things is, I can't tell WHAT the system
> resource is. Memory? Temp disk space? File Handles? Back in the old
> DOS days there was a limit on the number of files a process could
> open. Could NT have a similar problem?
I am not a hardware expert, but in my humble opinion, controllers either work
perfectly or you get a drive not found error. Try switching the drive cables
round, you might have an intermittent cable, if one of the address lines is
marginal then it may only manifest itself on certain areas of the drive. If the
problem moves with the cable, then replace the bad cable. Otherwise,
keep the same drives, but move them around (so that the physical
drive on F: is one that you know is good), see if the problem moves
to the drive that used to be F, then you might have replaced a bad
drive with another one. You might then want to fix the drive
letters, so that the F: drive is on a different physical
drive/controller port, so and see if the problem moves to the drive
on that controller port, then it's the controller. If the problem
says on navco99.gdb no matter what you move around, then the problem
might be NT.
I am not sure I would trust NT on a machine that has that kind of
load on it, I would seriously consider ripping out NT and replacing
it with a member of the unix family (Linux, *BSD, Solaris, etc).
For one thing the error messages usually make sense, and if not, the
vendors technical support or a NG can usually get you an answer
quickly. For another thing, because unix doesn't require the GUI
components, your not watching 25-50% of your resources going to
drawing pretty pictures. Plus the unixes have very different ways of