How To modify the DefaultView of a List


If you want to modify the DefaultView of a programmatically created list you have to know a “bagatelle”.

First i tried it this way:



and nothing happened at all.

The reason lies in the property DefaultView which encapsulates a behavior in which in every call the View is instantiated again. So in the first line you would modifiy the first instance of the view. Than, you would update a new instance of the View, which is not modified or updated.

So, knowing this, what you have to do to make it working is the following:

Get the Instance, modifiy it, and safe it.

SPView view = list.DefaultView;


How to set the default ContentType at a Library


Get All ContentTypes of the List.

List<SPContentType> ctl = new List<SPContentType>();
SPContentTypeCollection collection = list.ContentTypes;

Iterate over all ContentTypes of the List and compare your CustomContentType with all existing ContentTypes of the List. Compare the Name, not the ID.

Your CustomContentType has to be added to the List programmatically first.

Add the found/calculated ContentType to the List<SPContentType> ctl.

This is necassary in this manner, because after adding the ContentType to the List it gets a ID Appendix which you have to calculate first.

So if you would add your Custom ContentType directly to the List<SPContentType> ctl, it wouldn`t work, because exactly that ContentType is not existent at the SPList. When you add the ContentType to the SPList, it derives and has it`s own ID. So you first have to calculate the exact existent ContenType.

The complete Method looks like this:

private static void SetDefaultContentType(SPContentType CustomContentType, SPList list)
List<SPContentType> ctl = new List<SPContentType>();

SPContentTypeCollection collection = list.ContentTypes;

foreach (SPContentType ct in collection)
if (ct.Name.Contains(CustomContentType.Name))

list.RootFolder.UniqueContentTypeOrder = ctl;
catch { }


SharePoint Formulas

Hi there,

i`m searching this site every time i have to create a complexer formula. So this time, i thought, i put it  in my blog as a reminder ;-)


A thing, you should have a look at, is the language dependant syntax in the formulas, f.e. on a german SP Server you have to use the “;” semicolon as a seperator in your formula, but on an english server a comma “,”. This is not mentioned in the msdn.

If you think of I18N and Solution Deployment, this is really a thing, microsoft should standardize.


Nintex Maintenance Best Practices in english

If you are working with complex Nintex Workflows, you should always keep an eye on the maintenance of your Environment. You should have especially a closer look to the Nintex Content Database and the hidden List “NintexWorkflowHistory”, if you are working with loops inside the workflow. This is necassary to avoid to run into performance issues, which is essentially in long time scenarios. Your system will be affected by this problem sooner or later, depending on your Solution. This is a result of the built in Logging Mechanism which can end in a excessive Database growth. But, knowing this, you can use built in NintexSettings in your Workflow and schedule some BatchTasks to keep your environment healthy and performant. I just want to describe the possibilities Nintex is giving us.

Nintex generates per default the following Entries in the ContentDatabase:

Number of Rows
1 Row per Workflow
2 Rows per Action, which is executed
1 Row per TaskAction (Request Approval…)
1 Row for each Approver, which is participating to a Request
1 Row per each Delegation of a task

But that`s not all, there will be created a SPListItem for each executed Activity in the hidden List NintexWorkflowHistory. For example, i once found the List containing 4.5 Mio. entries affecting the whole environmentperformance massively.

But Nintex gave us some Tools to keep the System on track, even in Long Time Scenarios. Begin to avoid unneccessary entries to the db in your Workflow by Setting a Checkbox in the ConfigurationPanel of your Activity.


Just have a closer Look to the Common Tab. You will find a checkbox there “Hide from workflow Status”, which is disabling the Loggingmechanism for this Activity. After you published your Workflow again, this Activity is not logging to the db anymore, which also means, that you can not see the Appearance of the Activity in the WorkflowHistory either. So you should do this after debugging your Workflow and knowing that everything behaves as expected. You can also configure, that the Activity is only executed at business Times. This also reduces the amount of logging entries especially when you use Loops, which maybe are running some days.

You can get rid of existing Entries by using a tool named NWAdmin. You will find this tool in the folder: “C:\Program Files\Nintex\Nintex Workflow 2010”

Create some BatchFiles there and do the following things:

1. Synchronize Nintex with the MS Workflow Foundation / Sync Terminated Workflows

NWAdmin.exe -o SyncTerminatedWorkflows -url “http.//url” -verbose -showMissingItems –terminateDeletedItems

Maybe you deleted some documents without ending a running workflow, you may have a discrepancy in the Workflowstati safed in the MS Workflow Foundation on the one hand and Nintex on the other hand. Deleted Items have to be terminated in Nintex. So you can do this with this command.

2. Purge Workflow Data

NWAdmin.exe -o PurgeWorkflowData -url http://url -state completed  -verbose

REM States: completed/cancelled/errored/all

You can delete existing log entries in the Nintex DB. Maybe for completed Workflows or cancelled and errored Workflows. You can even configure to only delte entries which are older than n days to keep some informations available for a while.

3. Purge Workflow History

NWAdmin.exe -o purgeHistoryListData -siteUrl “http:URL” -verbose -batchSize 500 -state completed

REM States: completed/cancelled/errored/all

You can remove ListItems from the mentioned List NintexWorkflowHistory.


Keeping this in mind, you will have a long time stable Workflow Environment!  Some of the mentioned things are configurable now in the CA if you have the Nintex Version >2.2 installed. The ToDos are valid (or a must) for Nintex 2007 either.

Create some BatchFiles and use you TaskScheduler to automate this. It´s a bit tricky to automate the manually needed Submission with “yes”. If you want to know how that works, don`t hesitate to contact us at ecspand, d-velop or leave a Comment.

Happy Coding!


Nintex Maintenance Best Practices


Wer mit komplexen Nintex Worklfows arbeitet, darf die Wartung des Systems von Anfang an nicht aus den Augen verlieren. Spätestens bei Verwendung von Schleifen muss man ein Auge auf die Nintex Content Datenbank sowie die versteckte Liste NintexWorkflowHistory werfen. Macht man dies nicht, hat man je nach Workflowaufkommen früher oder später ein Performanceproblem. Ursache dafür ist der verbaute Logging-Mechanismus, der in einem starken Datenbankwachstum resultieren kann. Diese Erfahrung muss man wohl einmal gemacht haben, man kann sie aber von Anfang an vermeiden.

Bei jedem Nintex Workflow werden folgende Einträge in der ContentDB erzeugt:

Anzahl Beschreibung
1 Zeile pro Workflow
2 Zeilen pro Action, die ausgeführt wird
1 Zeile pro TaskAction (Request Approval…)
1 Zeile für jeden Approver, der einem Task zugewiesen wird
1 Zeile für jede Delegation eines Tasks


Außerdem wird für jede Action ein Item in der Liste NintexWorkflowHistory erzeugt.

Als Worklfow Designer hat man zum Glück einige Werkzeuge, um dem entgegen wirken zu können. Man ist schon im Nintex Designer in der Lage, das erzeugen von Datenbankeinträgen zu verhindern. Das machen Sie wie folgt:


In der Konfiguration einer Action gehen Sie in den Reiter Common und aktivieren die markierte Checkbox. Nach der Neuveröffentlichung des Workflows logt die Action nicht mehr in die Datenbank. Sie ist allerdings nun auch nicht mehr in dem Workflowverlauf sichtbar. Daher sollten Sie das erst durchführen nachdem Sie den Workflow nicht mehr debuggen müssen und er fehlerfrei läuft. Sie können außerdem darüber nachdenken Actions nur während konfigurierter Geschäftszeiten ausführen zu lassen. Auch das senkt die Anzahl der Logeinträge. Das können Sie in dem Reiter Action einschalten.

Bereits erzeugte Logeinträge behandeln Sie mit einem Tool namens NWAdmin, das bei der Nintex Installation mit ausgeliefert wird. Sie finden das Tool im Ordner “C:\Program Files\Nintex\Nintex Workflow 2010”

Mit diesem Tool (NWADMIN.exe) sollten Sie folgende Dinge durchführen.

1. Den Nintex Datenbestand mit der WorkflowFoundation synchronisieren / Sync Terminated Workflows

NWAdmin.exe -o SyncTerminatedWorkflows -url “http.//url” -verbose -showMissingItems –terminateDeletedItems

Sollten Dokumente ohne Beendigung des Worklfows entfernt worden sein, so werden evtl. bestehende Workflows in den Zustand cancelled versetzt.

2. Den Datenbankbestand aufräumen / Purge Workflow Data

NWAdmin.exe -o PurgeWorkflowData -url http://url -state completed  -verbose

REM States: completed/cancelled/errored/all

Mit diesem Befehl werden Logeinträge aus der Datenbank entfernt.

3. Die Liste NintexWorkflowHistory verkleinern / Purge Workflow History

NWAdmin.exe -o purgeHistoryListData -siteUrl “http:URL” -verbose -batchSize 500 -state completed

REM States: completed/cancelled/errored/all

Mit diesem Befehl werden SPListItems aus der Liste NintexWorkflowHistory abgeräumt.

Beachtet man obige Dinge, steht einem langzeitstabilem System nichts im Wege. Ab der Version 2.2 des Nintex Worklfows 2010 kann man meiner Kenntnis nach diese Wartungsarbeiten in der CA konfigurieren. Ansonsten gelten die obigen ToDos ebenfalls für den Nintex Workflow 2007.

Führen Sie diese Tasks am besten außerhalb der Produktivzeiten durch, da doch etwas Last auf der DB erzeugt wird. TaskScheduler… Wer wissen will, wie man das automatisiert sucht bitte einfach den Kontakt.

Happy Coding!

May 2017
« Dec    

Latest Comments

Badge Farm

  • Powered by Redoable 1.0