Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

At 11 AUG 2004 01:30:36PM David Craig wrote:

I'm in the process of setting up some exports of data out of our Arev database that run in the middle of the night. I set up a job on the server that launches Arev with a specific user, then check for that user in the logon program, call a couple of programs that export data to a local directory and close Arev. All this works fine but I'm having a problem: when Arev closes it's leaving a bunch of files open, and those files are getting skipped by the backup because they are open. The server is running W2K SP4 with the W2K service and NPP.

Am I doing something wrong by running a copy of Arev on the server? If not, does anyone have any idea why Arev would leave a bunch of files open like this when called this way?

Thanks in advance;

David Craig.


At 11 AUG 2004 01:38PM David Craig wrote:

A bit more information: the open files are the regular data files opened by the logon process, not the files the export program is creating, those are closed by the program that exports the data.

David C.


At 11 AUG 2004 05:50PM Steve Smith wrote:

Thinking out loud…

Is AREV.EXE / NTVDM visible in the Windows program monitor when you look first thing in the morning after the export has run? (ie does windows perceive the files as open)

Are you issuing a "PERFORM OFF" at the end of your program?

Are there indexing files involved? (is the logout being foiled by an index.flush which goes on forever)

Are there other users logged in to this AREV? (ie the problem is caused elsewhere)

Is a virus checker holding open the OV files? (is the problem caused by an external program?)


At 12 AUG 2004 07:30PM David Craig wrote:

]Thanks for replying.

Is AREV.EXE / NTVDM visible in the Windows program monitor when you look first thing in the morning after the export has run? (ie does windows perceive the files as open)

]I haven't checked for that but I will the next time I try it on the server.

Are you issuing a "PERFORM OFF" at the end of your program?

]Initially yes, in an effort to fix this I replaced it with

'chain "off"' which removes the program from memory. I noticed that whoever wrote the login program used that to bail out if the login failed and figured it was worth a try, although I doubt it will make a difference but haven't tried it yet.

Are there indexing files involved? (is the logout being foiled by an index.flush which goes on forever)

]That was my first thought and I'm pretty sure that's not it. The workstations are set up for background indexing only if the client is idle for a period of time, since the program just opens, runs some selects and writes out to a couple of text files I don't think indexing is starting up. I found that the 'logon' program opens quite a few files and it appears that's where the files that are open are being opened, what I don't understand is why they aren't being closed when 'off' is being called. They should be, right?

Are there other users logged in to this AREV? (ie the problem is caused elsewhere)

]Not at 4 AM in our test database.

Is a virus checker holding open the OV files? (is the problem caused by an external program?)

]I don't think so, we've been using the same backup routine for well over a year now and never had a problem before.

]I guess I can presume from your question (and the lack of other posts) that no one sees a problem with running a copy of Arev on the server like that. I'll try it from a workstation next, that should eliminate the server as a factor. When we try it from the server again I'll look for the VDM first thing.

]And I'll post a solution if I find one, thanks again for your help.

]David Craig.


At 14 AUG 2004 11:17PM Steve Smith wrote:

It occured to me that the server has write-caching and file handle caching happening - which may hold open files on a *server* longer than on a workstation potentially.


At 24 AUG 2004 01:34PM David Craig wrote:

This problem resolved itself. After rebooting the server to close the files it did not leave files open.

David Craig.

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/e911c65f7aa957ca85256eed00602fa8.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1