Goldmine 5.7 locking in SQL server

Users getting hourglassed and activity monitor shows blocking.

This was opened as another thread a month or so ago,
but that was closed when the problem sort of went away with not conclusive cause found.

Now after a month of so of not being a problem,  it's back.

"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.
Both of these steps were taken previously:
Alter Database  OurDatabaseName  Set READ_COMMITTED_SNAPSHOT on
"SQL 2005 in compatibility mode for 2000 it should be ok. "

I'm thinking another clue may be found by setting up individual SQL logins to perhaps isolate which user(s) are involved. Then investigate their activity, or machine? But that's a long shot as I'm pretty sure their machines are all set up the same way.

Anyone else seen this before?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

The only thing in that update query that is not total gibberish is


I suggest you try to find a record in your cal table with that recid and see if it provides any additional insight.

select * from cal WHERE RECID='7BEPPX1&2*>(JI9'

It looks so odd I'm tempted to call it something unkind, like "rogue query." But then I wonder if the query is really coming from GoldMine or from some other application, maybe a 3rd party product that wants to store it's licensing or usage or timeout data in an obscure place in GoldMine.

You've been able to "trap" that query as being something that hangs GoldMine. Question: Can you run a trace and see if you ever get queries like that when GoldMine is not hung?

Also you're idea: "I'm thinking another clue may be found by setting up individual SQL logins to perhaps isolate which user(s) are involved. Then investigate their activity, or machine?" is probably a good idea... it may add some additional insight if, in fact, the query does always come from the same machine or user.
awalkintheparkAuthor Commented:
Nice idea about the rogue query from another application, but I doubt it.
I'll try to trap that query when it's not hung.

This record:
select * from cal WHERE RECID='7BEPPX1&2*>(JI9'
has no userid, ondate, ontime or enddate
There are 31 records in the CAL table with
 ridiculous content in the Company field
COMPANY='20080919 13:06 20080919 12:57 20080922 09:24 20080922 10:36'
I would like to delete these using query analyser.
Any reason not too?

awalkintheparkAuthor Commented:
the 31 records have comparable data to:
"20080919 13:06 20080919 12:57 20080922 09:24 20080922 10:36"
they are not all exactly this.
Acronis True Image 2019 just released!

Create a reliable backup. Make sure you always have dependable copies of your data so you can restore your entire system or individual files.

I would delete them with the general caveat relative to deleting stuff which we don't know what it is. I have friends who decide to "clean out" their windows directory because they think it's bloated. Next thing you know, nothing works.

Having said that, I have no idea what those records are doing in your database, nor why any program should be sending queries in order to update it.

OK, never mind the above. I did a query on my GoldMine: select * from cal where company like '%:%' and boy did I get an earful.

The records in question all have accountnos beginning with PB and then a user's name. I think this is where GoldMine stores the user login data that you would see if you went into File | Config | Users Settings | Properties | Time Clock.

This means that the records are, basically, legitimate. Why your system hangs when GoldMine tries to update these records is still a mystery. Could well be related to the SQL version though. Your version of GoldMine was never tested with SQL 2005, only SQL 2000 (and possibly SQL 7).
Correction... PB = PegBoard. If you view the calendar and select the Pegboard tab, the information you see there comes from these records.
awalkintheparkAuthor Commented:
The processID#1, a system process, command "Resource monitor"  in SQL server activity monitor  is the other side of the blocking.
awalkintheparkAuthor Commented:
And it all seems to have gone away after  rebuilding indexes, reorganizing, checking integrity.
So, try that if you are in the same boat.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Just curious -- hadn't you already tried that before... without (lasting) success?
awalkintheparkAuthor Commented:
I think the first time this happened, I rebuilt the indexes, only.
So, I did all the maintenance steps reorganize, check integrity, indexes.
Don't know what to say, except that the problem is gone  for now.  Remains to be seen if it returns.
But there was a definite correlation between the maintenance routines completing and the problem going away. I do appreciate your help and time.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Enterprise Software

From novice to tech pro — start learning today.