DataAdapter/DataSet in non-form application??

  • Thread starter Thread starter Adam Clauss
  • Start date Start date
A

Adam Clauss

This may be more of a Visual Studio question than a C# question, but it came
up within the context of a C# app, so here it is.

In a Windows Form or a Web Form application, you can drag various
DataAdapters and create DataSets bound to them so everything is strongly
typed - a very nice feature.

Why in the world can this not be done the same way for ANY type of
application (say, Console, or Class Library). What do these features have
to do with form applications?

I know how to create the datasets myself (create a new dataset and, in this
case, since I'm working with SQLServer, I can just drag the table I want
over from the Server Explorer window). But what about the DataAdapters? Is
there some way that I've missed to set them up in the same manner?

Thanks!
 
Probably because console apps and classes in class libraries typically do
not require WYSIWYG type design. Where as windows and web forms do. This
also applies to user controls, etc - anything that by definition is going to
have composite controls/components on it.

Now, for console apps and regular classes, obviously the controls are
useless - there is no design surface to speak of. So you are left with
components - an example of which is the sqldataadapter. Now true, it is
possble for MS to have done something to help you out here - but would have
been a lot of extra work for them, for something frankly, not that useful.

Besides, you are better off not using the garbage the designer generates for
SQL related components. It is always better to write your own code and not
rely on the wizard, which not only generates a lof of extra stuff, but is
known to be buggy. Typically, the wizard really ties you down to specific
databases/tables, and is not very helpful in creating reusable code.
 
Marina,

Nice start and than I thought is Marina writing this????? That is the one
who never uses the wizards.

That you showed at the end of the message and than I understood it again.

However in my opinion there was not much to add at the end, you had written
it already that you can use it with all items that have a design surface,
and to give this message some sense as well for the OP even with a user
control. So when you add too a console application a component class, you
have your surface to use it.

:-)

Cor
 
Well, in this case I started off writing my own code, but I'm at something
of a loss at the moment. I'm using an image column type in an SQL table to
store various amounts of binary data (Yes, I know I could store it on the
file system and simply store the path to the file, but I have other reasons
application specific). Unfortunately, SQL queries seem unable to handle
this data type if the length gets too big (for example, for INSERT's). So,
I thought I would just setup a dataadapter and dataset to handle all this...
but apparently that's not possible.
Probably because console apps and classes in class libraries typically do
not require WYSIWYG type design. Where as windows and web forms do. This
also applies to user controls, etc - anything that by definition is going
to
have composite controls/components on it.
Click to expand...
So? OOP - the data should be completely separate from the controls anyway.
The fact that they are being tied together here isn't right.
components - an example of which is the sqldataadapter. Now true, it is
possble for MS to have done something to help you out here - but would
have
been a lot of extra work for them, for something frankly, not that useful.
Click to expand...
A lot of extra work? The work has already been done for form apps! And how
is it not that useful? If it a) works for my needs, and b) saves time, then
it is incredibly useful!
 
Adam,

You readed my message too Marina where in was a part extra for you as well,
in my opinion it should not be a problem at all.

Cor
 
Back
Top