Alex:
If you look at Help | About on the problem computer, can you confirm it says 9.0C (111209)? What if you open Sample data from that same computer? I expect your answers will be "yes" and "same thing" but let's check.

Hi Alex,

Access Violations are generic error messages given because a process was requested to be performed by the workstation and at that instant in time it could not be.

One reason for this error is a slow connection to the data (due to the network or a large amount of data to load), or a slow workstation. To eliminate the size of data as a cause, could you try accessing the sample data company from this workstation (\softrak\receivables\samdata). If the problem does not occur following the same steps, then the workstation is having a problem loading all the required data fast enough - where other workstations and connections are OK.

If you have a copy of your company data, could you place it on your local C drive and attempt to open the copied data and try the same steps? That would eliminate the data path difference and instead focus on just the program paths you posted above. If the behaviour is the same, then the problem is related to how the data is being accessed via the path.

From your prior posts, it appears to make the problem occur, you just have to open the company data and then click on the Customer toolbar button. Is there anything else open in Receivables, or are you pressing other buttons or 'double-clicking' the customer button? You should only be single-clicking the button.

I suspect that the problem lies with the workstation itself or the connection to the server/data, which is why no other workstation is having the problem.

Hi All,

I did confirm it says 9.0C(111209).

I opened the sample data found on the network and it still through the same error.

I moved the real data to the PC locally and still got the same error.

I also moved the sample data from the network to the PC and get the same error.

The PC is from 2008 and as I have said previously it will be replaced at the end of this week. We have 1 GB Ethernet everywhere in the office.

To get this error, I simply open Receivables and click on the Customers in the toolbar. I then get the first access violation.

It did just stop working on the 8th of December so it certainly looks like the machine.

Cheers,

Alex

Sounds like a machine RAM failure at this point.

Unfortunately, we have been seeing Access Violations in many Adagio Modules, and have reported it as well. And we were told that we are the only ones seeing it. But we see at client sites fairly frequently. The fact that you are also seeing Access Violations, doesn't surprise us at all.

We see it in Order Entry, Receivables, Payables, Inventory Control, General Ledger, with Terminal Services and Lans. Now we have not had the chance to test out the experience of changing to the new hot fix of Gridview, and most of our larger sites use Gridview extensively for custom queries. Perhaps that will help, and here's hoping it will.

In Order Entry, we can make it occur on demand, on both XP's and Win7. We have seen on many client networks, and our own. So I'm not buying the RAM Failure or or the network failure anymore either. Not to say that a defective PC or NIC or Cabling or Switch is not a possiblity, but I have my doubts.

We simply shut down the workstation and try again, or reboot. We have removed and reinstalled software applications to no avail. We will start to monitor again to see if the frequency goes down now that we are installing the recent GV Hot fix. We'll keep you posted.

Brian

Well Brian, can you suggest a better answer than a hardware problem given the following?

• It only happens on this machine.
• It doesn't happen when running a Terminal Server session.
• It started happening without any other change to the machine.

Access violations occur when a program attempts to read and/or write to memory not under its control. This can be the result of a program bug or hardware problem. Most access violations are harmless (although annoying), so we just report the error and continue, rather than halting the application, which we believe would be more disruptive. They will never go away entirely, as they can be created by race conditions in very specific hardware environments. Perhaps we should stop reporting them on the screen and simply log the occurrence in a file? However, that will mask problems that should be fixed, so I'm not sure it makes a lot of sense.

Perhaps you'd care to share the steps that can create this problem "on demand" with Steve and/or our Technical Support department as they have been requesting? The easiest way would probably be to record a video and send it to us using Jing.

Following up on this topic. The new machine arrived and we used the Windows Transfer Utility to move the user's profile over. This same error showed up on the new machine. We then created a new profile and did workstation setups and the error was not there anymore. Therefore the error must have been in the profile on the original machine. I have had to rebuild profiles on other machines before but I didn't even think of doing this as it looks like Adagio runs primarily from a network drive.

The new machine is working fine with the new profile so there is no immediate need to find a solution. I still have the old machine so I would like to test any ideas to see if we can't get to the bottom of the problem. Knowing that it is integral to the user's profile is a big step and will help us troubleshoot these types of problems in the future but I would like to entertain any possibilities as to what file/folder/registry setting is the culprit.

Thanks,

Alex Douglas, P.E.
Hoskin Scientific Ltd.

What "user profile" are you referring to?

The windows user profile.

Hmm - I've not known anyone to use the Windows migration to set up a user on a new machine. At Softrak, we always set up a new machine from scratch.

My guess is that there is a rights issue on the permissions of the old profile.