Company -> Blog...

December 23rd, 2015 by

Dear Paul,

Its seems our indexupdates table is growing.  What can be done?

Although this is an older issue and now corrected, you should still monitor the table to make sure that the indexupdates table is cleaning up after itself.

There are a few short steps for the potential resolution (the steps can be time consuming but they are not difficult) with SpeedSearch rebuilding.  I have some standard disclaimers because Speedsearch is very heavy on the Disk I/O and needs to be performed off hours when users are not on the system.  The steps below are easy but could take a long time to run depending on the amount of records in the database especially the history table.

  • First, backup your production Saleslogix database.
  • Second, truncate your indexupdates table.
  • Third, rebuild the indexes.
  • Fourth, test the results.
  • Lastly, communicate the results of the work.

Let’s review more details below ( I have a few more details than above):

My Standard Disclaimers apply.


  1. Kick off the users.
  2. Perform work off hours.
  3. Back up your database with verify options.
  4. Run the truncate table command on the indexupdates table.

Open up SQL Query analyzer, change the <Saleslogix Database Name>; to the name of your saleslogix database name and remove the <> characters and verify the following.  The Infor CRM (Saleslogix) kb article had the table name singular, but I believe it is plural, so correct me if I am wrong.

USE <Saleslogix Database Name>;


SELECT COUNT(*) AS BeforeTruncateCount FROM sysdba.indexupdates;


TRUNCATE TABLE sysdba.indexupdates;


SELECT COUNT(*) AS AfterTruncateCount FROM sysdba.indexupdates;

5. Stop the speedsearch service

6. Go to the Saleslogix Speedsearch folder with the Speedsearch indexes

Go to the SpeedSearch share folder as noted in the SpeedSearch configuration

7. Remove /backup the contents of each folder  (Note: not the folders themselves)

8. Start the Saleslogix speedsearch service

9. Login to the administrator as admin user

From the menu, Manage SpeedSearch Configurations

Schedule tab

Rebuild all the Full indexes

Rebuild all the incremental indexes  (this could take a while)

10. Test the results in the Saleslogix client/Web client or using SpeedSearch client in the network client.

11. Communicate the test results back to operations as needed.

Going forward it is good practice to review and optimize the Speedsearch index schedules to confirm they are running at staggered times. E.g. not all running at 12:00 AM, 6:00 AM which is not optimal, but is the typical default.  You may also have indexes running for areas that are not being used as well.  Speedsearch is a great tool and works well, but needs to be monitored and optimized.

Be sure you put your feet in the right place, then stand firm.

– Abraham Lincoln

If you would like to discuss upgrading your system, or to see a free demonstration, please contact Simplesoft Solutions.

Remember to check our CALENDAR and register for free training, demo sessions, and the Heartland Saleslogix Users Group Events.

Dayton/Cincinnati, OHCharleston, WVCharlotte, NC

Comments Off on Saleslogix Speedsearch Truncate the IndexUpdates Table



October 31st, 2014 by

Infor CRM (formerly Saleslogix) has this terrific engine called SpeedSearch that works behind the scenes and helps to index entities. The indices and structure is based on a third-party searching and indexing engine called dtSearch.  The main idea is that it provides high performance searching so that a user can perform a Keyword search and Saleslogix returns records based on that keyword.  It is well designed, integrated, and works well when it is properly configured and managed.   SpeedSearch comes in two flavors: Standard and Advanced licensing.  The main difference with the Advanced licensing is the ability to add and customize, which is outside of this discussion today.

The secondary function is that SpeedSearch helps to identify duplicates on imports using the lead import tool.  Speedsearch works in both the web and windows without any differences in result sets, as expected!  If there is one area of the tool that I would be critical of,  it is what I would call default madness.   This article is dedicated to helping administrators review the setup and configuration to make sure that they have reviewed and optimized the settings for SpeedSearch.  The various settings can have a huge impact to your end user experience.

First, we need to evaluate where you are with Speedsearch configurations and operations in place.  Is the SpeedSearch service running today?  Are indexes enabled and being run successfully?  Are they all set to the default of 12:00 AM?  Are the indices matched to the areas of your usage?

  1. Start | Run | Services.msc  and confirm the service is running
  2. Start | Program Files | Saleslogix | SpeedSearch Configuration  and confirm the basic configurations
    1. Check the servername,  Share Path,  and database options
    2. Start | Program Files | Saleslogix | Administrator | Menu for Manage | SpeedSearch Indexes…
      1. Confirm the indexes enabled
      2. Start | Program Files | Saleslogix | Administrator | Menu for Manage | SpeedSearch Configuration… | Schedule tab
        1. Confirm the jobs are running and which jobs are needed
        2. Table Check:  Select count(*) from sysdba.IndexUpdates to make sure that SpeedSearch is cleaning up changes after the index jobs are being ran.

Once SpeedSearch has been reviewed and confirmed operational, we have a few recommendations for optimization.

Top Recommendations:

Only index areas that are required for Infor CRM (Saleslogix) and areas of Infor CRM (Saleslogix) that are being used.  If you are not using defects for instance, turn off the index.

Only schedule the type of index jobs, adding change differences, for the areas required.   For instance if you are indexing Account, but you only need to see updates on a daily or weekly basis, then delete the incremental jobs.

If there are schedules for areas that are not being used (like defects mentioned earlier) delete them and make sure they are not enabled.

Stagger the times that the index build runs.  By default, they are set to run at 12:00 AM and if all the indexes are running at the same time that is not optimal and may cause issues.

So now you have evaluated SpeedSearch, thought through the changes to make, and lastly you need to schedule time to make the changes and confirm the results.  You will need to pause the services, make the changes, and turn the services back on.

Finally, you will need to monitor two areas.  First making sure the services are running properly and secondly the jobs are cleaning up the speedsearch tables properly.

Don’t dwell on what went wrong. Instead, focus on what to do next. Spend your energies on moving forward toward finding the answer.

Denis Waitley

If you would like to discuss upgrading your system, or to see a free demonstration, please contact Simplesoft Solutions.

Remember to check our CALENDAR and register for free training, demo sessions, and the Heartland Users Group Events.

Dayton/Cincinnati, OHCharleston, WVCharlotte, NC

Comments Off on How to Optimize and Cleanup SpeedSearch for Indexing Infor CRM (Saleslogix) Searches



April 14th, 2014 by

These excerpts are taken from the Saleslogix Knowledgebase and we thought these were so helpful in explaining some common issues that we wanted to share them with you here.  The steps below should speed up your system, substantially. Please call us if you have questions or would like assistance analyzing or executing these changes.

Take care to read the items thoroughly and pay close attention to the notes and warnings.

Before making any changes to your database we always recommend taking a backup of the database. Use ‘an ounce of prevention is worth a pound of cure’ kind-of-thinking…

Legacy Database Indices

What Happened?

All of the database indexes were rebuilt in a version of Saleslogix 6.2. As a part of the upgrade process, the existing indexes were to be dropped from the database, and then a script was to be run against the database to create the new indices. Support is seeing more and more instances of this part in the upgrade process being missed or ignored. The end result is a sometimes drastic hit on environmental performance.

Do I have the correct Indices?

  1. Open SQL Management studio on the SQL server.
  2. Expand the Saleslogix database.
  3. Expand the Account table.
  4. Expand Indexes.


  • The naming convention for the current Saleslogix indices is Tablename_fieldname.
  • Legacy Indices can have two possible naming conventions. They can begin with the letter ‘X’ or they will begin with “NAME”# (# = any number).

*Sample of a vanilla v7.5.4 Indices for Account:

If I have the legacy indices what do I do?

  1. Drop the indexes that match the legacy naming convention. WARNING: If you have any questions about which indexes to drop, contact Saleslogix support to help you to differentiate between legacy indexes and custom indexes your dba may have put in place.
  2. Restore a copy of the Saleslogix Eval database to your SQL server. Choose a version of the Eval database that matches your version of Saleslogix.
  3. Under the Eval database expand the target table until you can see it’s indices
  4. Right click on the 1st index you wish to copy. Select script index as, create to, New query editor window. NOTE: This will create a SQL script that when run will create the index.
  5. In the Query editor window you will see the name of the Eval database between brackets in the first line after ‘USE’. Change the name in the brackets to the database you wish to send this index to.
  6. Click Execute on the statement. NOTE: You should not see the Index in your target database.

NOTE: This process must be done for all legacy indices in the database. After completing these steps the database should have no legacy indices and all the new indices should be in place.

NOTE: These steps are considered SQL administration.


What Happened?

Over the years users may create allot of groups and it’s hard to know which are needed and which are not when trying to clean things up. However, there is one easy target that when removed can positively affect performance; the target is groups owned by retired users. The performance results may vary depending on the number of groups returned by the SQL statements below but, in some older environments where the number of records is above 5000 the performance increase of cleaning up groups owned/created by retired users can be significant.

Do retired users own groups?

In SQL run the following SQL statements to discover how many Adhoc and Dynamic groups are owned by retired users.

NOTE: The first select statement looks for a legacy user option that creates extra adhoc groups for no benefit.

  • Find Users set with this Legacy Option–

Select * from sysdba.useroptions where name = ‘creategrouponinsert’

  • Find Adhoc groups owned by retired users–

Select * FROM sysdba.ADHOCGROUP WHERE GROUPID IN (SELECT P.PluginID FROM sysdba.Plugin P LEFT JOIN sysdba.Plugin C ON C.BasedOn = P.PluginID

WHERE P.BasedOn IS NULL AND P.Type in (8,23) AND C.PluginID IS NULL AND P.UserID IN(SELECT USERID FROM sysdba.UserSecurity WHERE Type = ‘R’))

  • Find Dynamic groups owned by retired users–

Select * FROM sysdba.PLUGIN WHERE PLUGINID IN(SELECT P.PluginID FROM sysdba.Plugin P LEFT JOIN sysdba.Plugin C ON C.BasedOn = P.PluginID

WHERE P.BasedOn IS NULL AND P.Type in (8,23) AND C.PluginID IS NULL AND P.UserID IN(SELECT USERID FROM sysdba.UserSecurity WHERE Type = ‘R’)

If retired users own groups what do I do?

  1. If #1 returns records, delete this option for all users.
  2. If #2 or #3 have returns, delete all returns WARNING: take into consideration that the retired user may have shared some of these groups out to users who still actively use them.

NOTE: These steps are considered SQL administration which is beyond the scope of Saleslogix support. Support may be able to advise regarding this procedure but the execution is the responsibility of your SQL DBA or Saleslogix business partner.


What Happened?

When SpeedSearch is configured to index the Account table every changes any user makes to the account table generates a record in the IndexUpdates table. When SpeedSearch runs it reads the IndexUpdates table and applies the changes to a physical file on the hard drive. When it’s done with reading the records and applying the changes to the index files is cleans up after itself and removes records that have already been processed from the IndexUpdates table. If SpeedSearch breaks, or if someone has installed it but never configured it, the IndexUpdates table doesn’t get cleaned out and can have a mind-blowing number of records in it that can drag down performance across the whole environment.

Does my IndexUpdates table have a problem?

In SQL run the following statement, if the statement returns more than a few thousand records you likely have an issue.

  • Select Count(*) from IndexUpdates

If I have an IndexUpdates table issue what do I do?

  • In SQL truncate the IndexUpdates table

NOTE: do not perform a delete of IndexUpdates data as this will cause the database log to expand massively.

  • If SpeedSearch is being used, delete the physical index files and run all full and incremental SpeedSearch index schedules to recreate them.

NOTE: This procedure is recommended for the weekend as it will take a long time and drastically impact any users in the system.

  • If SpeedSearch is not being used, Uninstall SpeedSearch components on the server or assure SpeedSearch services have been disabled in windows services.

NOTE: Some of these steps are considered SQL administration.

Web Client Content Expiration

What Happened?

When using the web client several items are cached locally for every click and by default they are cached every time a user navigates certain areas of the client. However, some of the items being cached are not updated or changed and should only be cached once. Using the steps below to set content expirations on specific items tells the users machine to cache these items once and use the local copy until the expiration date is reached.

Do I have my content expiration set appropriately?

Use the following steps to check content expiration for the following SLXClient Site items.

  • Jscript
  • Library
  • Css
  • Images

1. Open IIS on the web server

2. Expand the Saleslogix website

3. Expand the SLXClient web application

4. Double-click on Css

5. Double-click on HTTP Response headers

6. From the top right, click ‘Set common headers’

NOTE: If the Expire Web content checkbox is not checked and the After field has no value, content expiration has not been set.

How do I set content expiration?

7. Select the checkbox to ‘Expire web content’

8. Click the ‘After’ radio button.

9. Enter the desired expiration date.

NOTE: Generally set this to 200 days

10. Follow the steps above for all 4 items listed above.

11. Reset IIS

NOTE: The content expirations must be set in IIS after every build and deploy in the Saleslogix Application Architect.

If you would like to discuss upgrading your system, or to see a free demonstration, please contact Simplesoft Solutions.

Also, if you would like to learn more tips, or have a CRM topic you would like us to write about, please contact Simplesoft Solutions, Inc.

Remember to check our CALENDAR and register for free training, demo sessions, and the Heartland Saleslogix Users Group Events.

Dayton/Cincinnati, OHCharleston, WVCharlotte, NC

Comments Off on The GOOD STUFF On Speeding Up Your Saleslogix System




scroll up

Hit Counter by technology news