04-09-2009 09:09 AM
More accurately, when he double clicks on the Contact list in the Account Detail (main) view. His SLX hangs as (Not Responding). Eventually it loads but it takes quite a while. When I do the same thing as Admin on my desktop, the screen loads quickly. No hang up.
We have very recently upgraded from v6.2 to v7.5.
This error was not present pre-upgrade, and appeared post-upgrade.
Are there any specific adjustments I can make to Options, Client Settings, etc. that will improve performance?
What actions is SLX taking when one opens a list of contacts from the Account Detail screen?
04-09-2009 09:22 AM
Just to make sure I understand correctly.
You upgraded from 6.2 to 7.5.
Do you have this problem in Network or Remote client?
Does the user has this problem only with this one account or also with others?
What happens if other "normal" users open this account?
You can see if SLX is doing something, when you open the slxprofiler and see what happens.
In general I have not seen this kind of issue.
Have you run the integrity checker to make sure your database has no errors?
04-09-2009 10:36 AM - edited 04-09-2009 12:26 PM
Thanks for your response.
This is a problem with a network client.
Problem is only with one account, however it is an unusual account in that it has over 600 contacts. So other accounts may also have delays, but far shorter due to lower contact/activity count. Most accounts have fewer than 12 contacts.
I ran the integrity checker and found database errors which will be repaired tonight.
SLXProfiler didn't trap any errors but we saw the CPU usage spike as we navigated from one contact to another. So it must be working fine, but just taking a long time to do something. Hmmm... then I saw that the user had a tab open that or BP added that lists "all History for the Contact's Account." For this account, there are A LOT of entries in History.
Other "normal" users (who don't have the customized Notes/History tab open) don't see this behavior.
So I believe that this error is just a function of the size of the dataset in our customized Notes/History tab. However, we did NOT see this type of slow response in v6.2.x The SQL driving the datalist is:
SELECT A1.HISTORYID, A2.TEXT A2_TEXT, A1.COMPLETEDDATE, A1.USERID, A1.CONTACTNAME, A3.DESCRIPTION A3_DESCRIPTION, A1.RESULT, A1.DESCRIPTION
HISTORY A1 INNER JOIN PICKLIST A2 ON (A1.TYPE=A2.ID) LEFT OUTER JOIN OPPORTUNITY A3 ON (A1.OPPORTUNITYID=A3.OPPORTUNITYID)
((A1.TYPE<>262162) OR (A1.USERID='UserID')) AND (A1.ACCOUNTID = :BindID)
Q: Were there any changes that would explain this sort of slow response time?
04-09-2009 02:07 PM
I'd suggest a couple of "Speed-Up" tweeks:
A - Make sure EVERY FK (foreign Key) is indexed in the History Table as well as Contact table
B - Make sure that EVERY FK has a real value that points to something or set it NULL
C - Make sure that EVERY FK that is "blank" is set to NULL
Just a couple of starting points
Thsn you can use the SQL Optimizer in the SLX Profiler to help improve the actual (slo) SQL.
NOTE: This will NOT fix any remotes - ONLY the main so you will have to re-cut all impacted remotes IF you want these changes in the remote (office and/or user)
04-10-2009 07:07 AM
You mentioned that you customized the Notes History tab. Have you compared your customizations with the "Out of the Box" Notes History tab? Maybe something will show up there?
04-10-2009 08:42 AM
Also you had said that this a customized tab. In previous versions there were issues with some tabs not assiging a :BindID and loading all the records, then displying the correct ones. Perhaps this version of the tab has this problem.
You can find great info (and fixes) from a SalesLogix partners website at:
Thanks to Mike Spragg of Empath-E for the helpful info.
04-14-2009 08:48 PM
In days of old.....
grid.refresh caused a refresh of the data grid.
Now (SLX 7.2+) it's firing a ton of times.....
Run SLXProfiler.exe when you go to the tabs and note the number of times it retrieves the same data.....
Grid's now refresh....
when you set grid.sql.text
when you grid.refresh
when you set the grid.bindid
when the sql has a :BINDID clause in it....
when you return to the form from another form that was launched from the form and the form changes a databound value on the parent table. (WHAT?!!! OK, say you have Opportunity.SalesPotential on an Opp Products tab.....and you call an Opp Products.dataform that changes the amount of the SalesPotential....so when you return to the Opp Products tab from the data formthe base form fires off an OnFormChange...and the grid starts firing off.....)
4 items in the grid, no big deal. 600 or 6000? now you start noticing the multiple firings....
What we've done is get rid of BINDID, references to BINDID. We set those through grid.sql.text (WHERE ACCOUNTID = '" & gOppID & "' " instead of :BINDID). which automagically does a grid.refresh for you.
The only time you use a grid.refresh is when you have already set the SQL previously and truly need a refresh.