Username:
Password:
Please type the Two words with a space between them to prove you are a real human being.
Comma separated value (CSV) files are a simple and flexible method for exchanging data between applications. Most databases support CSV files as do many requirements management and systems engineering tools, including Cradle, Excel, DOORS, FileMaker, Access and Oracle.
The format of CSV files is very simple:
Cradle can export most data from a database in CSV format, and can import data in CSV format into most item types in the database, including:
When importing CSV data, you must define a mapping between the fields in the CSV file and the attributes of the database items that you are importing into:
Unless there are any more specific rules, assume that every attribute of items in a Cradle database is a string.
The general rules for strings have been described in the previous section, but are:
A “ character
would be represented as:
“A “” character”
When items are first created in a Cradle database, they do not have a version number and so this attribute can be left empty in a CSV file. When an item is reviewed into a baseline for the first time, it will be given a version number 01. When a new instance of this item is created, it will also have a version of 01. When this item is reviewed into a new baseline it will have the version 02.
So items that are not in a baseline (have an owner that is not PROJECT) may or may not have a Version. Items that are in a baseline (when they will have an owner of PROJECT) will definitely have a version number.
Items that are not in a baseline will have a Draft ID. This will be A unless the item is either a diagram or a specification, when the Draft ID can be any single character in the range A to Z. The purpose is to allow multiple drafts of the same diagram.
Items that are in a baseline will not have a Draft ID and so this attribute can be left empty if importing baselined information.
Cradle will automatically assign a Draft ID of A if information is imported that does not have a Draft ID specified and will force a Draft ID of A if information is imported that is not owned by the project (not in a baseline).
All dates in CSV files should be in the format:
yyyymmdd
such as 20090113 for 13 th January 2009.
When importing data, if Cradle needs a date and none exists in the CSV file, then it will use the current date.
All times in CSV files must be in the 24 hour format:
hhmmss
such as 172512 for 25 minutes and 12 seconds after 5pm.
When importing data, if Cradle needs a time and none exists in the CSV file, then it will use the current time.
All security classifications in CSV files should be integers in the range 1 to the number of security levels defined in your project schema.
Authors and last modifiers are Cradle usernames. Owners are Cradle usernames or team names or the reserved project owner PROJECT. All values must be in uppercase.
Category codes either have a single value or multiple values.
For single-valued category codes, the value should be the string value of the category code. If the category code has a list of pre-defined values, then the category value in the CSV file should be one of these values.
For multiple-valued category codes, the value should be a concatenation of all of the values set in the category code, separated by | characters (| is sometimes called the pipe character). For example, if a multiple-value category code has values aaa, bbb and ccc defined, then the CSV file could contain:
aaa|ccc
which would set the values aaa and ccc in the imported item, but would not set the value bbb.
Frames are either text or binary. Binary frames do not necessarily contain binary data, such as Word documents or images. A frame whose frame type has a storage mechanism that is not In PDB is a binary frame even if it contains (or references) textual data. A text frame is a frame that has a storage mechanism of In PDB and contains text.
The storage mechanism in a frame type defines how the data in frames of the frame type will be stored, as one of: In PDB, As File, By Command or As Reference.
Binary frames cannot be output to, or imported from, CSV files.
Text frames can be output to, and imported from, CSV files. Separate paragraphs in the text frame should be separated by LF (linefeed) or CRLF.
Text frames should always be surrounded by " (double quote) characters, even if their content does not require it. This is simply so that you can be assured that the frame will be imported successfully, even if it should ever contain any " (double quote) characters.
Change histories cannot be output to, or imported from, CSV files.
So that Cradle can import data from CSV files into the database, it must be able to identify each database item from the import data. This means that the CSV import data must contain all of the attributes needed to identify the type of item that is to be imported. The mandatory attributes required to identify each type of item in a Cradle database are:
Where:
When importing from CSV files, you must ensure that all of these fields exist in the CSV file. They do not all need to have data in them, but they must exist, for example:
When importing from CSV files, you do not need to import from all fields in the file, you can skip fields, that is, not define any attribute to receive them.
The pre-defined Requirements item type only needs Number, Version and Draft ID values to identify an item in the database. A simple example that will import information into the pre-defined item type Requirement is therefore:
R1,,A,”This is an example requirement” R2,,A,”This is another example requirement” R3,,A,”This is a third example requirement”
In this example, the R1, R2 and R3 are the requirement IDs and would be imported into the Number attribute. The Version number is empty and the Draft ID is set to A. The text would normally be loaded into the TEXT frame.
To import information into system notes (user-defined item types), the CSV file must have values for the attributes Type, Number, Version and Draft ID. A simple example file that will import information into a user-defined item type SBS is therefore:
SBS,1.2.3,,A,”This is part of the SBS” SBS,1.2.3.1,,A,”This is a child of the previous item in the SBS” SBS,1.2.3.2,,A,”This is another child of the item in the SBS”
In this example, the Type attribute has the value SBS, the Number attribute has the values 1.2.3 and so on, the Version number is empty and the Draft ID is set to A.
Cross references are more complex to import than other information types because there are more fields that must be specified. A simple example that will import cross references between the requirements in the first example is:
,REQ_REQ,MH_IGNOREMODEL,,R2,DECOMPOSES TO,MH_IGNOREMODEL,,R3
In this record:
An example of cross references between system notes (user-defined item types) to create the hierarchy between the SBS items in the previous example is:
,NOTE_NOTE,MH_IGNOREMODEL,SBS,1.2.3,,MH_IGNOREMODEL,SBS,1.2.3.1 ,NOTE_NOTE,MH_IGNOREMODEL,SBS,1.2.3,,MH_IGNOREMODEL,SBS,1.2.3.2
In these records:
Full details of the alternative contents of the attributes of cross reference records are in the Cradle on-line help and user manuals. But, if you want to see some examples, generate a CSV export of the cross references in the DEMO project supplied with all Cradle systems.
Back to the newsletter archive.
