Another probable cause is RAM or motherboard. I ran into a couple of situations recently where the BIOS did not see any problem in the POST, but Norton reported a bad memory address. Sure enough, when I executed a simple batch file in the DOS Window involving XCOPY32.EXE, Windows 98 gave me a warning message saying there was insufficient memory to run the program, not at all likely. In the most recent case encountered just a few days ago, the motherboard was an Abit KT7 with 256 MB of SDRAM installed in bank 0, and a 128 MB of SDRAM in bank 1. Removing the 128 MB of RAM module solved the problem. So running RBase on a computer with a bad memory address seems fine until your data meets that bad memory address. I always use Norton to test the memory.
Stan Loo ----- Original Message ----- From: "Troy Sosamon" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, September 28, 2001 10:46 AM Subject: RE: Index corruption > Index corruption falls in the same class with database corruption, and thus > 99.9% of the time one of the following is happening. You get database > corruption from a database operation that does not complete. So, what will > interrupt the operation from completing? Among R:base developers, I think > everyone will agree on these things, I may forget some more obscure ones, > but we really don't agree on which happens most often. I will give you my > list: > > 1. Power - make sure every machine on the network including hubs, routers, > and servers has a UPS. It does not have to be a great big one, just one > that will take care of the brounouts and keep your machine up for 5 min when > the power goes out. > > 2. Bad NIC. > 3. Bad port on a hub, or bad hub > Both 2 and 3 will may cause random pack losses. > > 4. Other faulty hardware - Mother bord, HD.... > > 5. User interruption. Make sure that you don't have users closing R:base in > the middle of a transaction, or maybee a machine is locking up randomly. > > On large networks, it is like looking for a needle in a haystack. > > Troy > > ===== Original Message from [EMAIL PROTECTED] at 9/27/01 5:28 pm > >I do lock the table & if the table won't lock, then someone has some type of > >lock (usually an edit lock) so it informs the user to have others in the > >dept to exit the table and then the user can try the program with the append > >operation again. It appears that the index problem exists BEFORE the append > >is attempted. Trying the append just reports that there is an indexing > >problem. As users, throughout the day add/edit rows in the accounting > >table, the indexes will get updated, thus, the indexes for this table (as > >well as many other tables) are in a constant state of flux. > > > >I have indexes on computed columns in other tables that are accessed by > >everyone and haven't had problems with those tables. > > > >My questions again are: What can cause the corruption of the indexes on the > >table and how can I discover which index or indexes on the table are > >corrupted. > > > > > > > >-----Original Message----- > >From: Troy Sosamon [mailto:[EMAIL PROTECTED]] > >Sent: Thursday, September 27, 2001 9:09 AM > >To: [EMAIL PROTECTED] > >Subject: RE: Index corruption > > > > > >Try putting a lock manual on the table before you do the append and then > >take it off. > > > >set lock tablename on > > > >append..... > > > >set lock tablename off > > > >Troy > >
