SDU - User contributions [en]

Pdm load

2008-07-03T15:28:28Z

Mikelm:

Use pdm_load to insert, update or remove data into the database and bypass the GUIs.<br>
pdm_load uses the SeviceDesk virtual DB Schema layer to access the physical database.<br>
Contrary to direct Database access by ODBC for example, each data change is directly propagated to all ServiceDesk processes.

== Usage ==
pdm_load -f [filename] [-a] [-c] [-e] [-h] [-i] [-m] [-v] [-r] [-u] [-x]
<br>
{|
|-
! Command
! Description
! Remarks
|-
| -a
| update all matching data
|
|-
| -c
| check only, no change to data
|
|-
| -e
| treat escapes literally
|
|-
| -h
| help
|
|-
| -i
| insert only
|
|-
| -m
| notify domsrvr of mass update
|
|-
| -v
| verbose
|
|-
| -r
| remove
|
|-
| -u
| update only
|
|-
| -x
| use locale sensitive numeric input formats
|
|-
|}

== Examples ==
* A standard load. This load assumes that the file contains ids or uuids for all entries.
pdm_load -f extract.txt -v

* Using the -i to load data will force the creation of new ids and uuids. The file being loaded should be void of any id and uuid data.
pdm_load -f cnt_data.csv -i -v

* Removing some info (not shared by another application) from a file. Use the -r
pdm_load -f InfoToRemove.dat -r -v 2>load.err

== Notes ==
When doing a pdm_load of a ca_xxxxxx table that contains references to another ca_xxxxxx table, the reference must be valid or the entry will not be loaded and an error generated. For example, if loading the ca_contact table, if the ca_location_uuid field contains references to the ca_location table, then the record that is being reference MUST exist in the ca_location table or that particular entry will not be loaded. A common scenario is to perform an extract of the production contact data and then load it into development. However if the contact tables has references to the ca_location table you will first need to do a load of the ca_location table to ensure that all the references from the ca_contact load are valid. And if the ca_location table has references to the ca_site table, you will need to do a load of ca_site to ensure all the references from the ca_location load are valid.

----
<div align='center'><font color="red">To make corrections or additions to this article, select the ''edit'' tab above.<br>
To discuss or ask questions about this article, select the ''discussion'' tab above.</font></div>

[[Category:Commands]]

Object

2008-02-20T22:53:31Z

Mikelm:

Mainly, an Object in ServiceDesk is an object oriented representation of a single database record.

An Object belongs to a so called [[Factory]], which is somehow a mapping to one (or two) database table(s).

Normaly, each field in a table is mapped to an attribute in its object representation.
----
Changes to attributes of an object are always done in a three step process: First you have to checkout the object. That means, you tell the system, that you want to change this specific object.
If nobody else is actualy changeing this object, you get a writable version of this object. Then you are able to change the values of the attributes of the object. At the end, you have to do a checkin to this object.
The checkin will write the changed attributes to the database and makes the changes persistent.
----
In addtion to the data representation, objects can also implement application behavior in form of tirggers an methods.
There are two different kind of triggeres:

'''1)''' [[Attribute trigger]]: These triggers are fired, when an attribute is written or initiated (while the object is checked out).

'''2)''' [[Object trigger]]: These triggers are fired, when the whole object is checked in(saved).

Both kink of triggers are executing so called [[Spell]] code. [[Spell]] code is a proproitary script language, which can interact with each process of ServiceDesk and is able to do addtional changes to other objects or call other object methods
----
Addtionaly, an object may have addtional runtime attributes, like [[QREL]], [[BREL]], [[LREL]] and so called LOCAL attributes.

QREL, BREL and LREL Attributes can hold a list of other objects, while a LOCAL attribute is like a normal value (tablefield) attribute, but is not persistent, which means, it will not be stored in the db.

Object

2008-02-20T22:53:02Z

Mikelm: New page: Mainly, an Object in ServicDesk is an object oriented representation of a single database record. An Object belongs to a so called Factory, which is somehow a mapping to one (or two) ...

Mainly, an Object in ServicDesk is an object oriented representation of a single database record.

An Object belongs to a so called [[Factory]], which is somehow a mapping to one (or two) database table(s).

Normaly, each field in a table is mapped to an attribute in its object representation.
----
Changes to attributes of an object are always done in a three step process: First you have to checkout the object. That means, you tell the system, that you want to change this specific object.
If nobody else is actualy changeing this object, you get a writable version of this object. Then you are able to change the values of the attributes of the object. At the end, you have to do a checkin to this object.
The checkin will write the changed attributes to the database and makes the changes persistent.
----
In addtion to the data representation, objects can also implement application behavior in form of tirggers an methods.
There are two different kind of triggeres:

'''1)''' [[Attribute trigger]]: These triggers are fired, when an attribute is written or initiated (while the object is checked out).

'''2)''' [[Object trigger]]: These triggers are fired, when the whole object is checked in(saved).

Both kink of triggers are executing so called [[Spell]] code. [[Spell]] code is a proproitary script language, which can interact with each process of ServiceDesk and is able to do addtional changes to other objects or call other object methods
----
Addtionaly, an object may have addtional runtime attributes, like [[QREL]], [[BREL]], [[LREL]] and so called LOCAL attributes.

QREL, BREL and LREL Attributes can hold a list of other objects, while a LOCAL attribute is like a normal value (tablefield) attribute, but is not persistent, which means, it will not be stored in the db.