Goldmine 5.7 Hourglass for all users

If the random annoying period is long enough, please see if you can log on to GoldMine using the server itself as a workstation. I'd like to eliminate network artifacts like cabling, routers, and, especially, dns.

Oh, an here's the real smoking gun from days gone by... ask your users if any of them are running a GoldMine report during this time. If so, the only solution is to make them stop! ;)

The workaround is to redesign the report using Crystal, which will not cause the rest of the system to hang thusly.

No reports, this was running fine on another server on the same LAN. I don't suspect cables or routers.
DNS - they are all configured to use DNS services on the domain controller and this seems to work.
Any machine not using that, but the DNS servers at our ISP instead lags considerably, so they all point to the DC. One thing that may be pertinent is that  in SQL Activity monitor  one process is identified as a user using Net Pipes and the others are TCP.

FrontRange recommends tcp/ip exclusively... Suggestion: if no other application needs Named Pipes, turn it off, and force all GoldMine clients to use tcp/ip.

How long are the out-to-lunch pauses? a few seconds? multiple minutes? While the systems are hung are you able to do any diagnostics? I'd still like to eliminate any possible artifacts introduced by the network itself by running the client on the server directly. The two network connections to be concerned about are the file share connection to the GoldMine root directory and the connection to the sql server.

Oh, btw, 5.7 was not supported in SQL 2005. Not that it "shouldn't" work, but, well, one never knows. When it was running fine on the other server was the other server SQL 2005? or SQL 2000?

Freezes last 5 minutes or more. Now I see some blocking in activity monitor. "Blocked by"
references a processid that is  listed as a system process. This process was identified as user "sa" and
Command column was "TASK MANAGER".  Task manager was open on the server. I closed it and Goldmine thawed for the users. What! Why? Could be a coincidence, but I think not since the blocking
also resolved. Why would task manager even show up as a spid?  
This references the issue, but I think incompletely addresses the problem:
https://www.experts-exchange.com/questions/23581521/Task-Manager-Blocking.html 
I'm inclined to think this is the problem now, but would like to know what I can do about it other than kill task manager. The other poster didn't say if task manager was even open though can probably assume so.

I'm stunned. Never heard of such a thing before. Hard to believe Task Manager could do that. Any chance it's a virus, masquerading as Task Manager? If this turns out to be true, I've learned a lot, and I'll pay you ponts!!!

Virtually zero chance it's a virus.
Google search finds a few other people reporting the same thing.
It is hard to believe, but I closed task manager and immediately the users were unfrozen.

So, next step for you is to be sure Task Manager is not running? Keep it turned off for a few days, see if problem recurs?

I've now done this to the database:
Alter Database  OurDatabaseName  Set READ_COMMITTED_SNAPSHOT on
It seems better but not altogether gone.

In activity moniter, everytime there is a blocking situation, one of the threads involved with the blocking have
this query ( recid's vary)  
UPDATE dbo.CAL SET COMPANY='20080919 13:06 20080919 12:57 20080922 09:24 20080922 10:36' WHERE RECID='7BEPPX1&2*>(JI9' AND COMPANY='20080919 13:06 20080919 12:57 20080922 09:24 20080922 10:35'
I have rebuild indexes for this table.

1. I'm somewhat relieved (sorry if that's at your expense) that the Task Manager was not related to the problem. That made no sense to me.

2. The query you found is pretty odd. (I'm understating my feeling on this actually). It looks to be completely foreign to GoldMine's native functionality.

What, if any, add-ons are you running in conjunction with GoldMine? Has anyone there been "tinkering" with sql? Does your trace tell you the origin of the query?

No add-ons, no tinkering, I installed 5.7 fresh, but am using the database that's been in use for years.
I have just been told by another source that the problem is due to using sql 2005 with Golmine 5.7
I'm going to install a version of sql 2000 and see how that works.

Compatibility mode on the 2005 SQL server has been set to 80 all along.
Previous machine was NT 4.0 running SQL 6.5.

So, you'll revert back to SQL 6.5? or 7.0? or 2000? Seems reasonable. Good luck. Please post any other clues you come across that you think might be helpful. That query you posted looks to be about the strangest thing I've ever seen on a GoldMine system.

I'll try 2000. The current 2005 is set to 2000 compatibility  ( 80 )
Guess it has some differences from an actual 2000 DB.
I'll post a followup in a few days after I see what happens.
Thanks.

First day after user_committed_snapshot several locks and user complaints, then next day only a couple of locks, then past two, nothing. Whatever it was has seemingly stopped.

Sorry... are you saying the problem has gone away on its own without regressing back to SQL 2000? If so, you'll be on eggshells, not knowing what caused it to fail (and not knowing what fixed it), wondering when it will repeat again. Not that you can do much about it, and meantime just enjoy that it's working.

If I read you wrong, and the improvement follows reverting to SQL 2000, then I'm a little puzzled as to why that would make a great difference, but  c'est la vie!

Yes - without regressing to SQL 2000
I'm puzzled too, but it's working.

Thanks for helping out. Too bad it was not 100% conclusive.

OK, thanks for your feedback (and points). I've never seen this before, in the many years I've been supporting GoldMine.

Again, if it should recur, the first thing I would do is walk around and chat with the users to see if any of them have been "experimenting" with the built-in GoldMine reports. Some of them work fine, but others produce exactly the symptom you describe.