By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,277 Members | 1,200 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,277 IT Pros & Developers. It's quick & easy.

SQL programming. Working with auto-generated data objects.

P: n/a

Working as a beginner with data objects in Visual Studio 2003 and C#, I use
the "Generate Dataset" command in order to generate automatically the
dataset objects based on data adapters. Generated objects offer a convenient
way of working with database fields. For instance, if a database table
contains a "quantity" column, then, in the program, you will use expressions
like "row.quantity". This is more comfortable then writing something as
"row.getLong("quantity")", like we can do in other systems. We also benefit
by the IntelliSense help.

But, I noticed a thing that look for me like an inconvenient. The generated
get-accessors work with C# built-in types. For instance, if the "quantity"
is an integer column of a table, then the auto-generated get-accessor looks
like this:

public int quantity {

get {

... generated code ...

}

...

}

Since the return type is of type "int", this function, of course, will throw
an exception when the corresponding database field contains a NULL value. In
order to work with null-allowed database fields, Visual Studio generates one
more function, called "IsquantityNull()", of type bool.

I see here some inconveniences. We cannot simply get and store the database
value in a variable, like "int n = row.quantity" -- it will not work in case
of NULL value. Or, we cannot get and pass the value to a function, like
"printIt(row.qiantity)".

Therefore, we need to use a number of additional conditional elements in
order to work with nullable fields.

I am wondering why the auto-generated accessors were not designed to work
with their Sql equivalents, such as SqlInt32 or SqlString (defined in
System.Data.SqlTypes namespace). These structures allow storing of database
NULL value and checking for null. I think it will be much more convenient to
work with these kinds of data. The program will not be more overcharged with
conditional statements. Common problems like storing a database value for
later use, or passing it to a function will be easier to solve.

Does the above make any sense?


Nov 17 '05 #1
Share this question for a faster answer!
Share on Google+

This discussion thread is closed

Replies have been disabled for this discussion.