AF SDK Reference

CheckIn Example

Save PDF

CheckIn Example

Save PDF

Last UpdatedNov 18, 2025
6 minute read

CheckIn Example

The following example shows various mechanisms for making changes to AF objects and saving those changes to the server. In general, the simplest and most efficient mechanism is to check in multiple objects at once using the PISystem and Database CheckIn methods, however, others are illustrated for their behaviorial differences.

 1// Get the Default Database
 2PISystems myPISystems = new PISystems();
 3AFDatabase myDB = myPISystems.DefaultPISystem.Databases.DefaultDatabase;
 4
 5// You can create and modify objects and check them in one by one.  While this can be relatively
 6// simple, if there are many objects to be created, it will increase the number of round trips 
 7// to the server.
 8AFElementTemplate et = myDB.ElementTemplates.Add("T1");
 9et.AttributeTemplates.Add("A1").Type = typeof(double);
10et.AttributeTemplates.Add("A2").Type = typeof(double);
11et.CheckIn();
12
13// You can also "Apply" objects.  This saves the changes to the server, but only the current
14// logged in user will see these changes.  It is sometimes necessary to apply changes which might
15// affect other operations that require it.  For example, after changing a Template, applying those 
16// changes will allow the effect to be seen in objects created from a template.  Additionally, many
17// searches require changes to be applied before the search will be able to see those changes.
18et.AttributeTemplates.Add("A3").Type = typeof(double);
19et.ApplyChanges();
20
21// In general, it is faster to apply or checkin multiple objects at one time.
22// Use the PISystem and Database ApplyChanges and CheckIn methods.
23// PISystem.CheckIn is used for checking in objects which occur at the PI System 
24// level only (Notification Contact Templates, and UOM Database).
25// Note that it is generally preferable to check in only objects modified during 
26// the current application session (or the current thread for multi-threaded applications).
27AFElement rootElement1 = myDB.Elements.Add("MyPlant1");
28rootElement1.Elements.Add("E1", et);
29rootElement1.Elements.Add("E2", et);
30myDB.CheckIn(AFCheckedOutMode.ObjectsCheckedOutThisSession);
31
32//  The PISystem object contains a checkin which accepts a list of multiple objects.
33//  Use this method for finer control of what gets checked in than the Database.CheckIn method
34//  but still gain efficiency over checking the objects in one by one.
35AFElement rootElement2 = myDB.Elements.Add("MyPlant2");
36List<IAFTransactable> elements = new List<IAFTransactable>();
37elements.Add(rootElement2.Elements.Add("E3", et));
38elements.Add(rootElement2.Elements.Add("E4", et));
39myDB.PISystem.CheckIn(elements);
40
41// If you do check in objects individually, you should be aware that AFSDK may
42// check in other necessary objects on your behalf.  For example, if creating a
43// hierarchy, checking in a root element will cause NEW child objects to be
44// checked in as well.
45AFElement rootElement3 = myDB.Elements.Add("MyPlant3");
46rootElement3.Elements.Add("E5", et);
47rootElement3.Elements.Add("E6", et);
48rootElement3.CheckIn();  // E5 and E6 will also be checked in
49
50// Note that in the creation of Element Hierarchy, adding an object to another object
51// checks out the parent object.  
52rootElement3.Elements.Add(rootElement1.Elements["E1"]);
53rootElement3.CheckIn();
54
55// Event Frames behave slightly differently in regards to Apply Changes and Check In.  
56// In event frames, there is no user local storage (sometimes referred to as the Sandbox).
57// Once an event frame is applied, it is seen by all users.
58// Also, hierarchy behavior of event frames is slightly different as well.  In event frames,
59// adding a child event frame to a parent event frame does not check out or modify the 
60// parent event frame.  
61AFEventFrame efRoot = new AFEventFrame(myDB, "root");
62efRoot.CheckIn();
63AFEventFrame efChild = efRoot.EventFrames.Add("child");
64efChild.CheckIn();
65
66// Note that by default, when you attempt to modify an existing object, the AFSDK will attempt
67// to check out that object.  You can turn off this property by setting the 
68// static property AFCheckOutInfo.EnableAutoCheckOut to false;
69AFCheckOutInfo.EnableAutoCheckOut = false;
70try
71{
72    rootElement3.Description = "Attempt to change";
73}
74catch (InvalidOperationException ex)
75{
76    Console.WriteLine("Expected exception occurred: {0}", ex.Message);
77}
78rootElement3.CheckOut();
79rootElement3.Description = "Next attempt to change";
80rootElement3.CheckIn();
81AFCheckOutInfo.EnableAutoCheckOut = true;

 1' Get the Default Database 
 2Dim myPISystems As New PISystems()
 3Dim myDB As AFDatabase = myPISystems.DefaultPISystem.Databases.DefaultDatabase
 4
 5If myDB IsNot Nothing Then
 6    ' You can create and modify objects and check them in one by one. While this can be relatively 
 7    ' simple, if there are many objects to be created, it will increase the number of round trips 
 8    ' to the server. 
 9    Dim et As AFElementTemplate = myDB.ElementTemplates.Add("T1")
10    et.AttributeTemplates.Add("A1").Type = GetType(Double)
11    et.AttributeTemplates.Add("A2").Type = GetType(Double)
12    et.CheckIn()
13
14    ' You can also "Apply" objects. This saves the changes to the server, but only the current 
15    ' logged in user will see these changes. It is sometimes necessary to apply changes which might 
16    ' affect other operations that require it. For example, after changing a Template, applying those 
17    ' changes will allow the effect to be seen in objects created from a template. Additionally, many 
18    ' searches require changes to be applied before the search will be able to see those changes. 
19    et.AttributeTemplates.Add("A3").Type = GetType(Double)
20    et.ApplyChanges()
21
22    ' In general, it is faster to apply or checkin multiple objects at one time. 
23    ' Use the PISystem and Database ApplyChanges and CheckIn methods. 
24    ' PISystem.CheckIn is used for checking in objects which occur at the PI System 
25    ' level only (Notification Contact Templates, and UOM Database). 
26    ' Note that it is generally preferable to check in only objects modified during 
27    ' the current application session (or the current thread for multi-threaded applications). 
28    Dim rootElement1 As AFElement = myDB.Elements.Add("MyPlant1")
29    rootElement1.Elements.Add("E1", et)
30    rootElement1.Elements.Add("E2", et)
31    myDB.CheckIn(AFCheckedOutMode.ObjectsCheckedOutThisSession)
32
33    ' The PISystem object contains a checkin which accepts a list of multiple objects.
34    ' Use this method for finer control of what gets checked in than the Database.CheckIn method
35    ' but still gain efficiency over checking the objects in one by one.
36    Dim rootElement2 As AFElement = myDB.Elements.Add("MyPlant2")
37    Dim elements As New List(Of IAFTransactable)
38    elements.Add(rootElement2.Elements.Add("E3", et))
39    elements.Add(rootElement2.Elements.Add("E4", et))
40    myDB.PISystem.CheckIn(elements)
41
42    ' If you do check in objects individually, you should be aware that AFSDK may 
43    ' check in other necessary objects on your behalf. For example, if creating a 
44    ' hierarchy, checking in a root element will cause NEW child objects to be 
45    ' checked in as well. 
46    Dim rootElement3 As AFElement = myDB.Elements.Add("MyPlant3")
47    rootElement3.Elements.Add("E5", et)
48    rootElement3.Elements.Add("E6", et)
49    rootElement3.CheckIn() 'E5 and E6 will also be checked in
50
51    ' Note that in the creation of Element Hierarchy, adding an object to another object 
52    ' checks out the parent object. 
53    rootElement3.Elements.Add(rootElement1.Elements("E1"))
54    rootElement3.CheckIn()
55
56    ' Event Frames behave slightly differently in regards to Apply Changes and Check In. 
57    ' In event frames, there is no user local storage (sometimes referred to as the Sandbox). 
58    ' Once an event frame is applied, it is seen by all users. 
59    ' Also, hierarchy behavior of event frames is slightly different as well. In event frames, 
60    ' adding a child event frame to a parent event frame does not check out or modify the 
61    ' parent event frame. 
62    Dim efRoot As New AFEventFrame(myDB, "root")
63    efRoot.CheckIn()
64    Dim efChild As AFEventFrame = efRoot.EventFrames.Add("child")
65    efChild.CheckIn()
66
67    ' Note that by default, when you attempt to modify an existing object, the AFSDK will attempt 
68    ' to check out that object. You can turn off this property by setting the 
69    ' static property AFCheckOutInfo.EnableAutoCheckOut to false; 
70    AFCheckOutInfo.EnableAutoCheckOut = False
71    Try
72        rootElement3.Description = "Attempt to change"
73    Catch ex As InvalidOperationException
74        Console.WriteLine("Expected exception occurred: {0}", ex.Message)
75    End Try
76    rootElement3.CheckOut()
77    rootElement3.Description = "Next attempt to change"
78    rootElement3.CheckIn()
79    AFCheckOutInfo.EnableAutoCheckOut = True

No code example is currently available or this language may not be supported.

AF SDK Reference

CheckIn Example

Table of Contents

CheckIn Example

See Also

Reference

In This Topic

Related Links