TableAdapter Garbage

  • Thread starter Thread starter Mark Olbert
  • Start date Start date
M

Mark Olbert

First, a brief flame:

I am quite upset with Microsoft for destroying, hiding or constraining a lot of very useful features in the .NET Framework v2 that
used to be in v1.1. Guys, I really don't appreciate you making me learn a bunch of stuff in order to do tasks that were >>solved
problems<< in v1.1. I don't appreciate this "don't let the developer see it, hide everything from sight" philosophy that stinks up
v2. And, to add further insult to injury, declarative activities (e.g., creating a TableAdapter) involving actions against a
SqlServer2005 database are >>slow<<!! I used to be able to create a moderately complex SqlDataAdapter in 60 seconds. Now it takes
three minutes, most of which involves me sitting here twiddling my thumbs while >>something<< goes on between the server and my
development environment. If this is progress...I shudder to think what will happen when Vista arrives.

Okay, flame off.

Today's challenge is...why the heck isn't my TableAdapter for a simple table:

int idnum (identity field, primary key)
nvarchar(50) user_id
nvarchar(100) password
nvarchar(50) moniker
nvarchar(100) email
int flags

auto-generating row update and delete methods? GenerateDBDirectMethods is True...but DeleteCommand and UpdateCommand (in the
property window) show up as (None). Nor can I access the methods from code; they just don't seem to exist.

All the table fields are required (not nullable), BTW.

- Mark
 
Okay, the flame still stands, but the person responsible for the Update and Delete methods not being created was me. I thought I had
created the primary key for the table I was working with correctly. Unfortunately, I hadn't, so the table didn't have a primary
key...which is why the TableAdapter couldn't create Update and Delete methods.

I would suggest someone revies the TableAdapter so that it alerts you as to this type of problem.

- Mark
 
Mark said:
Okay, the flame still stands, but the person responsible for the Update and Delete methods not being created was me. I thought I had
created the primary key for the table I was working with correctly. Unfortunately, I hadn't, so the table didn't have a primary
key...which is why the TableAdapter couldn't create Update and Delete methods.

I would suggest someone revies the TableAdapter so that it alerts you as to this type of problem.

- Mark
Click to expand...
Mark:

I'll address the rest of your post in a second, but just as an FYI, any
of the autogenerate features, dataadapter, commandbuilders etc require a
key in order to work. I believe there's still a dialog though that
tells you at the end that the specific commands can't be generated but I
don't have it in front of me so i'm not positive. However i can tell
you with relative certainty that this aspect is here to stay.
 
Mark said:
First, a brief flame:

I am quite upset with Microsoft for destroying, hiding or constraining a lot of very useful features in the .NET Framework v2 that
used to be in v1.1.
Click to expand...

--Like what? What doesn't work in 2.0 that works in 1.1?
Guys, I really don't appreciate you making me learn a bunch of stuff
in order to do tasks that were >>solved
problems<< in v1.1. I don't appreciate this "don't let the developer see it, hide everything from sight" philosophy that stinks up
v2. And, to add further insult to injury, declarative activities (e.g., creating a TableAdapter) involving actions against a
SqlServer2005 database are >>slow<<!!
Click to expand...
--Again, like what specifically? Please note I'm not being
argumentative, I just don't follow where you're coming from, so
hopefully I can explain some of it away.
I used to be able to create a moderately complex SqlDataAdapter in 60
seconds. Now it takes
three minutes, most of which involves me sitting here twiddling my thumbs while >>something<< goes on between the server and my
development environment. If this is progress...I shudder to think what will happen when Vista arrives.
Click to expand...
--Are you speaking of a problem with the Adapter itself or the visual
tools? From the sound of your post it sounds like it's mainly with the
visual tools, is that correct?
 
Here's some of what I've noticed so far (just the big things):

- the radical change to how ASPNET sites are built (e.g., as one observer put it, "it's not even a project anymore")

- adding connections, SqlDataAdapters and Datasets to ASPNET pages is gone

- the close relationship between XSD files and Datasets is gone (i.e., you can't manually, or semi-automatically, create a Dataset
from an XSD file)

- the general adoption of dynamically-generated class files (e.g., VS2003 created a class file to define a Dataset built off of an
XSD file)

There are, of course, some things about version 2 that I appreciate. But the point is, it's a disservice to your customers to make
big shifts in how a development tool works -- you provide for transitions, not abrupt changes.

The same thing happened a few years ago when VB.NET came out. I recall the loud complaints of many developers about how it was too
radical a shift in the language. That particular abrupt change didn't affect me, because I made the switch to C# and haven't gone
back. But I did that, in part, because it was touted as NET's "primary" language, so I was expecting it to evolve, not go through
punctuated equilibrium :).

- Mark
 
Because, dude, I was doing something where I would've had to write a lot of boilerplate stuff, and thought I would benefit from all
the enormous productivity benefits promised by NET2. I have written my own stuff when it makes sense.

But, why should I have to write stuff myself when there used to be a perfectly adequate "automated" approach which someone at MS
decided to remove.

- Mark
 
Another one I should've included:

- major changes to the VSNET IDE involving moving frequently used options around

- Mark
 
Ehh .. well, lets put it this way - sure the new stuff sucks, but the old
stuff sucked too. It just sucks in different places.
In other words, some problems have been fixed, and some new ones created. I
cant' defend MS on TableAdapters because I am not sold on them myself, but
truthfully the drag drop approach wasn't a great solution to begin with
anyway :-/

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________
 
Here is my take on the points you mention below --
- the radical change to how ASPNET sites are built (e.g., as one observer
put it, "it's not even a project anymore")
Click to expand...
Yeah and that projectless model sucks. The compilation model is good though
because it makes managing ASP.NET projects easier. So it's a bag of status
quo. Though MS is working on a web project - so stay tuned.
- adding connections, SqlDataAdapters and Datasets to ASPNET pages is gone
Click to expand...
Not really - because you have new equivalent objects, and you can still do
that in code-behind - which IMO is the only serious way to do it anyway.
- the close relationship between XSD files and Datasets is gone (i.e., you
can't manually, or semi-automatically, create a Dataset
from an XSD file)
Click to expand...

Incorrect, datasets are still based on XSDs.
There are, of course, some things about version 2 that I appreciate.
Click to expand...

Me too.
But the point is, it's a disservice to your customers to make
big shifts in how a development tool works -- you provide for transitions,
not abrupt changes.
Click to expand...

Yeah but MS gave out PLENTY of information before the transition. And my
upgrade has been fairly uneventful, but then I followed P&P and stayed
abreast with what was coming down the pipe.
- major changes to the VSNET IDE involving moving frequently used options
around
Click to expand...

Yeah like what?

- Sahil Malik [MVP]
ADO.NET 2.0 book -
http://codebetter.com/blogs/sahil.malik/archive/2005/05/13/63199.aspx
__________________________________________________________
 
Incorrect, datasets are still based on XSDs.

Yes, they are. But try making a Dataset from an XSD file that you author, using either the visual designer or the XML code editor.
It used to be very simple (I did it all the time, often to make app configuration files for Windows Forms applications). Now it's
difficult, and involves cutting and pasting stuff into an existing XSD Dataset file, which means it's no longer in sync with your
source schema.

As to what got moved around, two quick examples (I find more every day I use VS2005):

- the Exceptions dialog box (for choosing which exceptions to break on, and how) is no longer in the IDE by default, as it used to
be. You can add it back by customizing the menus...once you think to go looking for it.

- Rebuild Solution/Project are gone (although it looks like you can add those back, too)

- rather than autogenerated source code files we get dynamically-created assemblies (which is a cool feature...but I liked being
able to "see" what was going on under the hood; being able to do so solved some nasty bugs for me in the past)

My point is simple: when you bring out a new product, you don't casually break with the immediate past. You provide a transition.
VS2005, and NET2, have a lot of cool new features. But they also have a lot of breaks where there should not have been. It's not
helpful to me to be constantly tripping over "where did that go?", "why is that no longer feasible?", etc.

I think the Web project addendum that's currently in beta is a wonderful example of what was done wrong with NET2 and VS2005: make
it "simpler", and hide the details. That's fine for making your simple personal website. It's not fine for making even a
moderately-slick site (as has been pointed out by many). I think even MS realizes this now, or they wouldn't be rushing a new
project model out the door (I applaud them for doing so. But I hope they demote the person who failed to think about the real-world
consequences of abandoning the NET1/1.1 model in the first place). This turnabout also shows that, however long NET2 and VS2005 were
under development, and however much information they circulated, it wasn't enough.

I also get the feeling that significant parts of NET2 were rushed out the door, despite the fact that it was in development for a
long time. That opinion may be the result of my wrestling with the shortcomings of the highly-touted Membership API (it's not at all
obvious how to implement a derived MembershipUser class; all of my attempts so far have ended up causing exceptions in the ASP.NET
Configuration tool -- even the one where the "derived" class is really just the MembershipUser class itself, i.e., I haven't added
any properties or methods). Yes, it can take a load off your plate...if you agree to do things precisely the way MS intended you to.
If you don't -- like if you want to add some additional fields to what you consider a user -- you're SOL. That's not good design.
But it is "simple". To be blunt, I'm fairly confident that I could design a better Membership API than the current one...and that's
not good, because I'm just one reasonably experienced but by no means expert developer.

As someone once said, a framework is a voluntarily worn straitjacket. But a >>good<< framework lets you undo the buttons and ties
and do things that let you solve your problem without having to shoehorn it into a cookie-cutter design. I personally think the .NET
Framework is, overall, one of the best examples of a good framework around.

But many of the changes (at least the touted ones that I've been trying to use) between 1.1 & 2.0 did not exemplify the best of what
was in 1.1. They feel like bolt-ons, rather than carefully-crafted additions.

- Mark
 
Ehh .. well, lets put it this way - sure the new stuff sucks, but the old
stuff sucked too. It just sucks in different places.
In other words, some problems have been fixed, and some new ones created. I
cant' defend MS on TableAdapters because I am not sold on them myself, but
truthfully the drag drop approach wasn't a great solution to begin with
anyway :-/
Click to expand...

LOL! I agree. But I think that reinforces my point: you >>definitely<< don't want to break with the past (as opposed to providing
evolutionary transitions) when what you're introducing has problems of its own.

In aggregate, developers invested many (thousands? tens of thousands?) hours learning how to make those parts of NET1.0 & 1.1
"dance"...which effort is now flushed down the crapper because "everything's changed".

- Mark
 
Mark,
Yes, they are.
Click to expand...

No they are not. An XSD is a way to describe a dataset using XML and from
which a dataset class can be generated.

A dataset is a normal class, which holds properties, methods and events and
has some special interfaces.

In my opinion unlucky enough is taken a different approach with the
generating of a strongly typed dataset from an XSD in a project and in
website. The first generates automaticly direct a strongly typed dataset
class and the second uses the XSD to do that in runtime and uses the object
hidden internally (reachable by the ObjectDataSource class).

This does not make it in my opinion real transparant. (In a webservice
application it is nicely done to make the web dataset available in a
windowsform application).

I have not yet seen a tool as in 1.x that generates from a XSD a strongly
typed dataset class in 2.0 style (the difficult is probably that it needs
the information

For me the benefit of the 2.0 strongly typed dataset (and makes it usable
what in my opinion the one in 1.x was not) is that it integrates the
retrieving and the description of the data. By changing the XSD using the
designer, it is now easier to change them than to have them to change in at
least (when done well) in two classes as it was in version 1.x.

I hope this helps (to get some ideas).

Cor
 
"> I have not yet seen a tool as in 1.x that generates from a XSD a strongly
typed dataset class in 2.0 style (the difficult is probably that it needs
the information
Click to expand...
Here I wanted to delete this line because it would be to much text
disturbing the general idea.

There is information in a strongly typed dataset which is in a website in
the web.config and is in a project in the app.config, done in different
ways, and hard coded in the (website) dataset XSD.

Cor
 
Cor,

There's an XSD behind a dataset in NET2. I've seen it by opening the dataset with the XML editor (from the context menu). I've also
edited the XSD in the XML editor and had that update the dataset.

- Mark
 
Nope, that's not what I said. I didn't say it broke all the code; I said the transition from 1.1 -> 2.0 wasn't well handled, and
that an important design principle -- don't break with the past unless you have to -- wasn't followed as thoroughly as it should
have been.

- Mark
 
Mark,

There's an XSD behind a dataset in NET2. I've seen it by opening the
dataset with the XML editor (from the context menu). I've also
edited the XSD in the XML editor and had that update the dataset.
Click to expand...

Of course exactly as you write it. It is the description of your dataset. It
is not the dataset.

But you can do it as well very good without that XSD.

In VB
Dim ds as New DataSet
dim dt as New DataTable
dt.columns.Add("Mark")
ds.tables.add(dt)

In C#
DataSet ds = new DataSet();
DataTable dt = new DataTable();
dt.Columns.Add("Mark");
ds.Tables.Add(dt);

Or Strongly Typed in VB (however not the same as generated and not with an
XSD)
public Class myDataset
inherrits Dataset
etc. and than the fields properties methods event as you use.
end Class

In other words the XSD can be the template for a dataset however is that not
forever.

Our website is full of samples where we create (small sample) datasets
direct the code

http://www.vb-tips.com/default.aspx

I hope this helps,

Cor
 
Now, kids if you can't play nice...

It turns out that the old Wizards are still there--they never left they were
simply shelved. If you customize the toolbox and search for DataAdapter
you'll see they're all there--just unselected. I assume these are what
you're missing. I also think it was a challenged decision to hide these, but
I'm just one voice. The Create New DataSet menu is gone too but you can
create an XSD-based (strongly typed) DataSet by adding a new item to the
project and choose "DataSet". This launches the DataSet wizard that builds
the XSD. However, you have to build your project in some cases to generate
the code.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
INETA Speaker
www.betav.com/blog/billva
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Sure, you've always been able to create a dataset programmatically. I should've been clearer -- I was talking about the changes in
the visual designer.

- Mark
 
Back
Top