Anyone knows what happens when the FDS special services crashes and then restats by itself?

We have a small WF db which crashes very often. We are incline to think that the SU drops control over this database when FDS crashes.

Can we test the staus of the databas and by pass it if it is broken?

Robert

This message has been edited. Last edited by: Kerry,

Robert

Please start upgrading your signature so we know better what version you are using and what platform.

Second give some more information about the procedure you are running, the size of the database and the Master description.
What is "very often" every time you do what? does it work sometimes, crashes after 10 days???

Can you see something in the log files?

Sorry about that, I am a consultant working at several clients so I do not have a single point of reference.
Our client is running on Windows 2003 server platform the 7.6.4 version of a reporting server, in the background we have resources analyzer. The application uses 4 copies of the same master file because we had to solve the problem with the 2GB limit on a focus DB (running on a older version client did not want to up grade the DB as yet).
The database giving us problems is less then 10MB and has the exact same master file as its 1.6GB brother. We have a batch job running to loading 10 logs coming from different telephone exchanges at a time. The database crashed 3 out ten times (several times a day). We reduced this to 3 logs and it crashed 1 out 1000 times (once every 3-5 days) which is strange. We have to check the status and make backup copies every few hours.
The program that loads this database has to work with a XFOCUS database that is 2.4GB ( the log information is stored here from the very first log for each telephone exchange), what happens is the program runs through the log and compares its it with the stored information and then extracts new information from the logs and tries to find data that results in what is called a down time event (when a telephone exchanges is not working).
We have very few events about 0-10 events per telephone exchanges. So the end result is added to the database that crashes. We noticed that it takes about 4 min. to ETL a single log into the database, the process is working as expected because of all the special handling that has to be done except for the DB crashing.
Also we have users running maintain (there is a program that uses the same DB) and table queries at the same time. We have checked the program and even though it is over 1000 lines of code e have not found any reason for it to cause the DB to crash. We are incline to think that SU has dropped control over the DB.

It is our shop's expierence that once the FDS (SU) crashes, even though it states it has "restarted" itself, it really hasn't and unpredicable results can happen afterwards. Sometimes an admin issuing the stop and start fds cmds will bring it up fine, other times the webfocus software needs restarted. This has been expierenced on different versions / platforms.

Robert
What is the Maintain procedure doing? Is this a batch procedure or are there forms? In your SUPROF or EDAPROF do you have SET COMMIT=ON? Check that. It IS required for Maintain.

Mark

To check the status of your FOCUS data base, you can use the ? FDT and ? FILE commands. The former checks the physical characteristics of the file which probably would be most interested in if perhaps some pointers got messed up during the FDS crash.

Thanks for your response.

Using the ? FILE we get an error message, could we test on the error code? If we can then we could fetach a backup and run the ETL pgm again.

The Maintain pgm is using forms and the set commit is on. The maintain pgm is being accessed by other uses for manuell up dating dring which the ETL pgm (using both modify and maintain) can be updating one of the same DBs. The problem DB is a new addition to the whole thing which has been working without problems before. There is limit in maintain as to how many DBs you can use at the same time and we are clsoe to it. This could be the problem but we are guessing.

If you are getting an error message, look it up on the IBI site or in a manual to find out what it means. It may be that your file is corrupted. If you can restore from a backup and can afford to possible lose data, then do that. Otherwise I'd open a case with IBI and have them help you.

Thanks Ginny.

I am look for a reason why the WF DB crashs giving
(FOC389) FOCUS DATABASE PAGE INTEGRITY VIOLATION DETECTED IN: SHD00000FOCTEMP

This has affected two other DB.

Robert
That error is due to Maintain and the shadow pages that are kept to ensure database integrity. In the past I have found that issuing COMMIT statements after database commands solves this issue.

The commit statement breaks the lock on the database and that seems to solve the problem. Look in your code for NEXT, Include, Update and Delete statements and see if placing COMMIT after these statements solve the problem.

Mark

Thanks.

That is most helpful. We will try it and keep our fingers crossed.