My customer was posting a batch in Invoices 8.1B, to A/R 9.0A. There were two invoices in the batch, both with a large number of items and a large dollar amount. After making an Invoices backup, posting was attempted. The program hung mid post, and she was forced to close it. She called me after checking the batch and customer. The batch was still listed as unposted, but in the customers A/R info both invoices were listed. We ran data integrity checks on both A/R and Invoices data, with no errors detected. I ran syscheck and there was no problem detected. They normaly keep a posting journal of everything posted. There is no journal for this posting. The batch is still sitting in Invoices. I have taken a copy of customer data if needed for analysis. The customer is using Windows XP Pro on a Novell server. I believe the novell client options are set as recommended by Softrak.
How should I proceed to resolve this issue?

Hi,

If the batch isn't posted, there will be no posting journal. Also, the invoices won't be in History for future inquiries, reports won't be updated, etc..

It's probably best to restore from a prior backup.

If they're using Novell, they should make sure that all of the latest client service packs have been installed and that opportunistic locking, file caching and file commit are turned off.

I am a bit confused. Shouldn't file commit be set to on?

From Novell description of option (in client settings)

-Controls whether buffers flushed by an application are committed to disk on the server. Setting this value to On will ensure data integrity at the expense of performance by ensuring file buffers are committed to disk on the server when an application flushes its file buffers.

Further to this problem, I feel all the settings are correct. The thing I am suspicious of is the number of items in the invoices. This customer routinely does invoices with 350 to 500 items per invoice. The batch we are trying to post has 371 items in one invoice and 444 items in the second. This customer had no problems doing this with DOS Quick Invoice. Would it be possible to send the data to support and have them try to post the batch? That would remove any possibility of the network or workstation being the cause of the problem.

Rather than sending the data to support, why don't you restore a backup to your C: drive and test it there - that will remove the possibility of the network being the cause of the problem. If it still fails, then try it on someone else's C: drive.

Finally, try the same thing with sample data, both on the network and locally. If sample data works, but your real data fails, that tells you it's a data issue.

I think with the results of these tests, you will be able to determine what is causing the problem.

Are you certain that the posting process really hung, and that it wasn't just a user getting impatient with a process taking longer than normal? How was the program "stopped"? Show your user how to add the read I/O bytes and write I/O bytes columns to the task manager so that they can see whether a program has appeared to hang just because the disk got busy.

Thanks for the suggestions. The problem appeared when posting this batch, not and others before now. The main difference was these were the first batches with such a large number of items. I tested this last night, and it hung for me as well. I waited 10 minutes for the two invoices to post, and windows came back said the program was not responding. I also tried posting from two other workstations with exactly the same response. The only thing I did not try was to copy the data to the workstation hard drive. I will do that tonight as I am one the road today. I will do as you suggest Andrew and turn on the option you suggest, although I am not familiar with it. I am sure it will be easy to find. Thanks again. I will update you tommorrow.

Just a FYI that getting a "Not responding" message about an application is completely meaningless in Windows. It more usually means that the application is too busy doing something (like writing records to the disk or downloading information from the network) to process a mouse click, than that the application has hung.

I spent quite a bit of time today doing testing on this problem.
First off, I copied the data to the local "C" drive as Steve suggested and posted there. It posted the batch with two invoices totalling over 700 items in 15 seconds flat, versus 28 minutes on the Novell server. A testament to your code Andrew. I turned on the option you suggested Andrew, and I could see the reads and writes happening as you described. Suspecting a network or Novell problem, I copied the data to the Windows Terminal server, where it took almost 35 minutes to post! My next step was to connect the workstation and both servers to a new gigabit ethernet switch, with nothing else connected. The test post was repeated. It made no difference. It still took about 28 minutes on the Novell server and 35 minutes on the Terminal server. I then installed the Adagio software on the Terminal server, connected via remote desktop and posted. The data posted in less than 15 seconds, the same as with the local copy on the workstation. It appears when the number of line items in a batch gets large that the network becomes an issue. I am wondering if keeping the data and programs on the Terminal Server would be a bad idea in this case. There is seldom more the three or four users working at one time, and mostly they are are on different data sets at the same time. The Terminal server notes say this is not a recommended or supported method.
Do you have any other suggestions? They do not appear to have posting issues untill the large line item invoices are posted. Thanks for your assistance!

I vote for either their virus checker on the server getting in the way, or an old, flakey, 10 Mbit hub connecting them to the server.