Saleslogix server locking up.....

[steve_v...@my-deja.com]

We just bought a new Pentium III Quad Processor 2 gig memory server for
our Saleslogix server. Even with this server we still have occasional
lock ups on our Workgroup users as they work in SLX (They last on and
off for 30 mins or so). It is not a Network problem as Outlook
functions normally. It doesn't seem consistent with the Synch server
though with a server as powerful as we have, it shouldn't matter. WE
have a 1.5 gig SQL database and approx 45 WG users. Any ideas,
suggestions, recommendations?

THanks
Steve
P.S. DOes anyone else experience these lock ups?

Sent via Deja.com http://www.deja.com/
Before you buy.

[corey_h...@my-deja.com]

Hey Steve this is Corey in KC,MO. Remember me from the training?

Your server problems,

What exactly locks up on the WG users pc? Is it just the SLX or the
whole systems? Could it be a SQL client problem?

CH

In article <8i340c$bit$1...@nnrp1.deja.com>,

[dan4t...@my-deja.com]

Well, occasionally we've seen WG users creat blocking locks on each
other, which is easily detected in enterprise manager. Usually the
blocking user hitting F5 clears everything up.

Perhaps you tried this already, but thought it might be helpful.

[steve_v...@my-deja.com]

Really? This might be what's causing the problems. What happens is
someone changes something and then moves on and people around him or
her begin to lock up. Would blocking locks cause an almost cascade
effect? It eventually clears itself up but it's hell for the minutes
it is locked up.

In article <8ip9k7$9uj$1...@nnrp1.deja.com>,

[dan4t...@my-deja.com]

It's never been such a widespread problem that I bothered investing a
whole lot of time in it. Generally at my site it happens once a month
or so and only affects one or two users. Firing up Enterprise Mgr
and looking for locks takes all of 60 seconds, that plus the phone call
to the blocking user ("Please press F5") generally resolves things
within 2 minutes.

Then again, there are only 3 or for WG users actually making changes at
my site. I suspected that the # of writers is more the root cause of
the 'cascade' issue than network proximity. Boy was I wrong...

Surprise surprise, I actually found something USEFUL in the support
knowledge base looking for 'lock':

SLX: MS SQL SERVER LOCKS DATABASE CAUSING INDEFINITE HANG
Document ID #99022448

PROBLEM:

MS SQL Server sometimes does not release locks after an application is
finished retrieving data. Locks accumulate until eventually an entire
table is locked and the database freezes.

This article recommends several things, including settings in WG admin
that may help your problem. It also says "don't use the ALL groups".
Doh! What's the friggin' point!!!

Anyway, take a look, this may solve your problem!

-D4P

In article <8ivqlj$ri$1...@nnrp1.deja.com>,

[steve_v...@my-deja.com]

Interesting! I searched on Lock and did not find that. Case matters
hen searching their site. Thanks. We had it set to 4,096. I changed
it to 40,000. What is yours set to? SHould I set it to -1?

Thanks
Steve

In article <8jecab$cga$1...@nnrp1.deja.com>,

[mea...@my-deja.com]

Hey guys,

there are some known issues with these locks but many of them have been
resolved in the latest versions of SalesLogix.

The biggest problem is the way SalesLogix open dynamic record sets
using cursors.
If the entire recordset is not brought back all related records (and
most of the time the 8k pages used by MSSQL) stay locked.

Make sure your settings help eliminate this:
On the client, go to tools -> client options and select the general tab.
Make sure that the MSSQL Server setting for the number of records to
pre-load is set to -1.

The behavior change will be that when you open a group, the selection
indicator will go to the bottom of the group.
This will pre load the entire group and release the locks.

There are other issues with locks (our database is huge (almost 9gb)
and we still hit them once in awhile) and they mostly stem from groups
that access records that are being modified.
Make sure any custom groups are small groups and are not being
constantly being modified by the same people.
If a group is open and a person enters or modifies a record that will
add or remove from that group you can get locks at the server.

Also, since you are using MSSQL I will give you another tip.
You may notice that the larger your database gets, the longer it takes
to log in.
Log in performace on MSSQL is terrible because SalesLogix forgot to
index a few fields in the history and activity tables.

Make sure that the type and userid fields are indexed or every time you
log in the database does a complete table scan of the history table
(this hurt us because we are getting close to 1.5 million records in
it).

Another tip to speed up finding locks.
Use query analyzer and the sp_who and kill commands instead of the
enterprise manager.
Microsoft ha a log of overhead in the queries they use in the
enterprise manager for looking at locks and you can often get a page
lock in the master database by looking for a lock.

Using sp_who in query analyzer will work much faster and has almost no
chance of causing a lock itself.

In article <8jff6j$4lk$1...@nnrp1.deja.com>,

[steve_v...@my-deja.com]

Awesome! I will check this out. I was unaware of Enteprise manager
and the potential for locks that it can cause!

THanks
Steve

In article <8jnmaf$s21$1...@nnrp1.deja.com>,

[mea...@my-deja.com]

Sounds like you have an awful lot of faith in the quality of Microsoft
products.
Beware...

Also - I forgot to mention...
Make sure you apply MSSQL sp2 if you have not.
TDS packets (which are used by the bde) can sometimes have some null
values in the header and cause a dll conflict that will force you to
reboot your MSSQL server.

sp2 will solve this for you (it is a Microsoft bug)

In article <8jqqbo$16s$1...@nnrp1.deja.com>,

[steve_v...@my-deja.com]

Was actually ahead of you on that one. We loaded SP2 when we created
the new server. :-)

In article <8k1pr7$pp5$1...@nnrp1.deja.com>,