From your code it's evident that you want ExamFile to be a collection of Exam objects. Exams have names and a collection of Question(s), and Question has two string attributes, Remark and Type. This object model is easily expressed in C#:

public class ExamFile
{
public string Title { get; set; }
public string Name { get; set; }
readonly public List Exams = new List();
}

public class Exam : List
{
public string Name { get; set; }
readonly public List Questions = new List();
}

public class Question
{
public string Remark { get; set; }
public string Type { get; set; }
}

You could construct the object graph and then set properties as in your posted code, like this:

ExamFile file = new ExamFile();
file.Add(new Exam());
file.Add(new Exam());
file.Exams[0].Questions.Add(new Question());
file.Exams[0].Questions.Add(new Question());
file.Exams[1].Questions.Add(new Question());
file.Exams[1].Questions.Add(new Question());

and then do as in your posted code

file.Title = "Test";
...
file.Exams[1].Questions[1].Remark = "tough question";

However, in most cases you'd create a question object and set it's properties before adding it to an exam. Also note that the types themselves should usually have constructors that take some parameters. This has two side-effects: Less code to write to use the type, which is not very important but a marginal benefit, and a guarantee that an instance of a type cannot be created without certain minimum information. Types should typically be designed to be flexible and general. Coding convenience can be achieved by writing little "helper methods" separately from the type itself. In this case, you could do something like this:

void addQuestion(Exam e, string remark, string type)
{
Question q = new Question();
q.Remark = remark;
q.Type = type;
e.Questions.Add(q);
}

Exam addExam(ExamFile f, string name)
{
Exam e = new Exam();
e.Name = name;
f.Exams.Add(e);
return e;
}

ExamFile file = new ExamFile();
f.Title = "test";
f.Name = "my first exam.mfe";

Exam e = addExam(file, "First Exam");
addQuestion(e, "remark #1", "Mutiple");
addQuestion(e, "remark #2", "I don't know");

and so on.

Scott Barbour wrote:

I typically use isnull(field,'') <> '' as our users are wont to make fields empty strings.

If you do not want to represent two different things by null or empty string, why is the field nullable in the first place? In my view, using invariant representations is a virtue. (Of course, there may be some cases where null and empty string is different for some purposed but not others, and then I guess this technique might be useful.)

You're certainly right about how it actually does behave. But I don't really see why comparions with null ought to behave differently in SQL than in, say, C#. This whole design decision of using the is operator for comparison to null seems illogical and counterintuitive, but I presume there is some reason for it. If you see a good reason, would you care to elaborate?