469,644 Members | 1,781 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,644 developers. It's quick & easy.

SQL programming. Working with auto-generated data objects.

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

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
0 1373

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Zorpiedoman | last post: by
22 posts views Thread by Les Juby | last post: by
15 posts views Thread by Ramon F Herrera | last post: by
reply views Thread by gheharukoh7 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.