Like Howling Wolf said the message MCD:64 is that the network connection between the "local" machine and the server is lost. We have an IP phone at work that gets the 'connection' via the computer. If the phone is reset (hard boot) PDMS loses the connection too and you get message MCD:64
The computers that have this problem are they all the same way configured as the ones that do not have this problem? Did you try and change the lan cable of the computer that crashes out with one that does not crash out? It might be the computer at fault (network card) and not the network or PDMS. Does any other application behave in the same way as PDMS on these computers?
I feel your pain... I've been through many of these "mysteries"... Ping is not always the best proof. Just because you can ping it, does not mean you can punch through it. So, your data may be always hitting the server, but something could be restricting the access on occasion. Think about downloading a network sniffing tool like Wireshark (free) to watch the communications. It watches ALL traffic between you and the server (TCP, RCP, etc...)
Here are a few extra things to look for (will require involving IT):
First and Foremost, Check for Virus Scanning:
Often companies enable live virus scans on servers, and sometimes live virus scanning on Clients. From the server level, if data is being scanned during a PDMS DB Write, it will halt the Database session (causing a Dabacon error). If live virus scanning is enabled and there is no option around it, most applications will allow you to set a range of IP addresses that are not scanned. Usually, this is only within your Network Subnet. If the server and Clients are in a different subnet, that likely won't be an option.
Is it a global project:
Or, was it ever a Global project? PDMS usually uses TCP communications, except if a project is Global. Then, it also incorporates RPC (Remote Procedure Call) across port 135, and a dynamic range of ports specified by the network team (controlled on the server level). 135 is used for initial communications, and to establish the direct port for writing/reading data. Some companies are moving to block RPC, since many Trojans use this similar technology. Check and see if there are RPC restrictions, if you have a global project.
Conflicting application on the server:
Is there a network tool running on the server that receives updates at 4 hour increments? If so, it may be updating itself, and momentarily forcing down network access (can be pinged, but not allowing a pass through).
Data optimization:
Some networks use a WAAS that looks for data coming in, and attempts to optimize the data (by combining similar bytes streaming in). My experience has been that PDMS does not like to be optimized (imagine that). Try turning it off, if it is currently on.
Trace Route:
Trace Route is like ping, but it shows you every stop along the way (servers, switches, domain controlers, etc...). Run it from a CMD prompt.
[INDENT]tracert 10.1.1.1 (use your servers IP address) [/INDENT]
Here is a test option:
Copy the project local to a PC, and have a select number of users map a drive to the PC as if it were a server. Beat the ?$#! out of it with mass amounts of data, and try to break it. If you make it past your hiccup window (4 hours) then you have proven that your LAN is not the issue, and I would focus on the server at this point (or domain switches along the way).
Along the same line of thinking as 007 above.
Does the company use switches or hubs?
What about the network traffic between 12 and 1? Does the company start sending a lot of info at that time? As you know PDMS is very I/O intense.
The 6 or 7 occurences that happen - are they the same machines or does it hit machines randomly?
It may be necessary to do some detailed monitoring/tracing of your network. Are all floors/departments operating with the same speed in the network?
I've done only one project. In the end, I was co-ordinating the project. We had around 50 active users at the peak. We had fair share of above types of error. Fortunately, the project was controlled by some terrific guys (giants) in the Netherlands. Invariably, they'd help us to solve almost everything. The reason for this long description, I just reply by the gut-feel and some experience which I had on the project.
1. When the user has remained inactive for a longer duration, chances are that other users have updated, modified and deleted elements in the database. Now when the user becomes active and does some action which accesses random data (e.g. running clash, add all within vol etc.) there are floaters around due to unsaved data. This causes the error.
2. The best pointers in these cases, lie with the users. Tell your users, to save screenshots every time they get such errors. In the beginning it seems futile but helps in playing the investigator. Tell them to list it along with MDB, action and module.
3. The databases, need to be compact in size (I don't remember the size limit told by one of those guys!) but you need to carry out db maintenance periodically if you are reaching the peak of project.
Always read those logs. I almost got killed (figuratively of course :)) by not heeding towards the logs that appear. It was clash manager. But I guess, the game remains much the same. All the best!
