This project is read-only.

SLAM Events not being fired when updating sharepoint lists with code


I am having an odd issue with SLAM. When edits/updates/insertions/deletions are made to the SharePoint lists directly through the UI, then the SLAM tables are correctly updated.

All manual updates that are made through a web browser correctly trigger events that are logged in SLAMEventLog and the changes appear in the SLAM tables as expected.

The problem I am having is that when I update a SharePoint list programmatically (through code), no events are triggered in SLAM and the SLAM SQL tables are never updated. There are also no events that make it into SLAMEventLog. The code does however successfully update the SharePoint list, and the changes appear as expected within SharePoint.

For example, if I run this VB code, to iterate through a SharePoint list and update a column, the code runs successfully, and the changes appear in the SharePoint list as expected. But, no events are triggered in SLAM, and nothing shows up in the SLAM log file. Any help would be most appreciated!

If I run the sync operation in SLAM, the changes do show up in the SLAM tables as expected.
    For Each c As Microsoft.SharePoint.SPListItem In listItems.Items

        c("Allow Client Specific") = "1"



brjenkins wrote Nov 6, 2012 at 7:21 PM

Is the code you are running in a separate context, like a console application? In that case you would need to either add the app.config appSettings key AWS.SLAM.ConfigurationManager.Config with the physical path to the slam.config, or you can copy the slam.config to the same directory as the exe. I would expect programmatic updates to work if running in the site context, like a webpart or page, etc.

tarbini wrote Nov 6, 2012 at 7:56 PM

SLAM Version is:


tarbini wrote Nov 6, 2012 at 8:08 PM

Hi, thanks for your input. The application that inserts the rows into the SharePoint list is running as a Windows Application (.exe). I tried copying the slam.config file into the Debug and Release folders, but the issue persists. Any other thoughts?

wrote Feb 14, 2013 at 9:18 PM

michaelhanna wrote Dec 17, 2013 at 3:39 PM

we are facing the same issue here !! Did you guys find a resolution for that ?

awellenstein wrote Dec 17, 2013 at 4:58 PM

Michael, based on your post here: I don't think you have the same issue. Your code is running inside the context of sharepoint not a separate application.

@tarbini, did you ever sort out your issue?

tarbini wrote Dec 17, 2013 at 6:12 PM

Hi – unfortunately we were never able to solve this issue. I tried the recommended changes and the SLAM events just don’t want to fire when running code from a console or forms based application. This makes scheduling automated tasks that update SharePoint lists and SLAM tables impossible. The only workaround I have is to manually re-sync the SLAM tables (which is not feasible due to the time it takes for the full sync to run). When in a pinch I generally run the list insertion code and then manually throw the SharePoint list into Datasheet mode and update rows in order to trigger the SLAM events.

If anyone is able to solve this issue please advise!

awellenstein wrote Dec 17, 2013 at 6:40 PM

Well, I can tell you that we do all sorts of stuff in console apps and FBA applications that SLAM content. Are you using integrated security? That could be the issue.

tarbini wrote Dec 17, 2013 at 7:38 PM

@awellenstein – the SharePoint farm is running on Win Server 2008 64bit with WSS 3.0. The site uses Integrated Windows authentication against Active Directory.

See below for a quick code sample. If I run this code from the context of a web application and set it up to run as an application via IIS then the SLAM events are triggered as expected. The code below is currently setup to run via a simple console based application. The console application is then scheduled via task scheduler and set to run with elevated privileges as an Administrator account. After the code executes, the changes in the actual SharePoint list are there and no issue with programmatically updating the SharePoint list. However when inspecting the SLAM tables we see that the events did not fire and the changes are not reflected in the synced SLAM tables.

If I then manually go into the SharePoint list (after programmatically changing it via code) and edit one of the updated rows, the SLAM event then correctly fires and the data makes it to the SLAM tables.

I also have this setup to run in a simple .NET windows forms based application and the issue persists.

Any thoughts or suggestions? Can you show me an example of the appSetting for Slam.ConfigurationManager.Config you are using when running code from a console application?
Dim site As Microsoft.SharePoint.SPSite
site = New Microsoft.SharePoint.SPSite("http://" & "servername")
Dim serverSite As Microsoft.SharePoint.SPWeb
serverSite = site.AllWebs("sitename")
serverSite.AllowUnsafeUpdates = True

Dim query As SPQuery = New SPQuery()
query.Query = String.Concat( _
"<Where><Eq>", _
"<FieldRef Name='CLIENT_ID'/>", _
"<Value Type='NUMBER'>" & "whatevervalue" & "</Value>", _

Dim list As Microsoft.SharePoint.SPList = serverSite.Lists("listname")
Dim items As SPListItemCollection = list.GetItems(query)
Dim item As SPListItem


If items.Count > 0 Then

item(colName) = Trim(tempstr)

End If


awellenstein wrote Dec 17, 2013 at 9:14 PM

HI @tarbini, you need to make sure that your console app can find the slam.config. Make sure you add:

<add key="Slam.ConfigurationManager.Config" value="C:[your-path-goes-here]\slam.config" />

to you app settings.


tarbini wrote Dec 17, 2013 at 11:19 PM

Hi @awellenstein - I already have this key setup in my app.config file but the issue still persists. I have even tried copying the slam.config file into the directory where the application is running but no luck. Is there anything special that I need to be doing when working with the SPListItem object in order for the SLAM events to fire?

Are you doing anything special with the authentication from your console application? Are you using Windows authentication from your SharePoint farm?


brjenkins wrote Dec 17, 2013 at 11:50 PM

@tarbini, just to verify, you are using the latest version of SLAM, correct? Your lists have the (6) SLAM event receivers attached? Calling Update on an SPListItem via console application, regardless of authentication scheme, so long as the items are accessible, will trigger the attached event receivers. We are assuming that much is happening. The common problem then for a console application slamming items is that the event receivers cannot find the slam.config.

If necessary you can reference the Slam.dll in your console application, add a using for Slam.SharePoint and use the "SlamUpdate" extension method on the SPListItem. If you do listItem.SlamUpdate(false, false) then you will just sync the item with the database. You would do that after calling Update on the item.

awellenstein wrote Dec 17, 2013 at 11:51 PM

What permissions are you using for the database connection in the slam config? If that's integrated security the issue is likely permissions.

Have you looked in the Slam message log to see if any errors were recorded?

brjenkins wrote Dec 17, 2013 at 11:55 PM

@tarbini, I read again that you are using the 2007 version. You can disregard my second suggestion then as SlamUpdate does not exist in the 2007 version.

The events should be asynchronous in the 2007 version, but they would definitely fire when calling Update from a console application. Were you already trying to use the config appSetting? The appSetting in the 2007 case would be called AWS.SLAM.ConfigurationManager.Config

tarbini wrote Dec 18, 2013 at 6:50 PM

@brjenkins - yes we are using WSS 3.0 (SharePoint 2007). I already have a config file setup with the console application that contains the appropriate keys. Please see below for my config file. I have tried this using both AWS.SLAM.ConfigurationManager.Config and SLAM.ConfigurationManager.Config with the same results. We are using SLAM Version: Do you think it would make a difference by updating to v2.0? My understanding was that this is supposed to work in v1.3 – was this issue specifically addressed in v2.0? Also I believe v2.1 will not work at all with SharePoint 2007 – is that accurate?

@wellenstein - the slam.config file is setup to use SQL authentication not Windows or Integrated authentication. This is the same slam.config file that is installed under the WSS virtual directories under c:\inetpub and it works brilliantly when lists are updated from the SharePoint web site.

I am also a server admin and have full access to everything. I have tried running the console application as an administrator and I get the same results. There are no rows generated in SLAMEventLog or in SLAMMessageLog when running this from the console application. It seems that the SLAM events simply are not being fired no matter what I do.

There are also no errors that appear in the Event Viewer. Everything works completely fine on the actual SharePoint sites. SLAM is definitely configured correctly for all virtual directories and the events always fire when updating lists inside SharePoint. We actually have three different virtual directories setup for SharePoint (One on Port 80 and two on port 443) - the SLAM events fire when updating lists from any of these SharePoint sites.

When I run this from code, the result is always the same - the SharePoint lists are correctly updated with insertions/updates but the SLAM events never fire.

I have also tried two different methods on the SPListItem - one that calls the .UpdateOverwriteVersion() method and one that calls .Update() - the result is again that the rows are updated in SharePoint but the SLAM events never fire.

I have also physically copied the slam.config file into every single folder that exists within the application folder tree and still no luck. If SLAM is not finding the config file, then I am not certain how else I can specify the location.

Any other thoughts or ideas?

<?xml version="1.0" encoding="utf-8" ?>
    <add key="AWS.SLAM.ConfigurationManager.Config" value="C:\mypath\slam.config" />
            <!-- This section defines the logging configuration for My.Application.Log -->
            <source name="DefaultSource" switchName="DefaultSwitch">
                    <add name="FileLog"/>
                    <!-- Uncomment the below section to write to the Application Event Log -->
                    <!--<add name="EventLog"/>-->
            <add name="DefaultSwitch" value="Information" />
            <add name="FileLog"
                 type="Microsoft.VisualBasic.Logging.FileLogTraceListener, Microsoft.VisualBasic, Version=, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL" 
            <!-- Uncomment the below section and replace APPLICATION_NAME with the name of your application to write to the Application Event Log -->
            <!--<add name="EventLog" type="System.Diagnostics.EventLogTraceListener" initializeData="APPLICATION_NAME"/> -->