its a pain!

[Bob]

I found it a real pain working with the datasets and table adapters and
bound records. Here's why.
During development I find I occasionally have to change some part of a table
definition. Say I forgot to make the primary key an identity column ,yeah
I'm human ;-). Typically I will find this out once the controls using the
erroneous table have been put on a form. I get the error message, fine so
far. Now I go into my sql server database and change the defintion. I click
on refresh for the dataset in the Vs data sources. Try again, still same
error. I found I have to remove the offending table from the dataset
defintion recreate the dataset definition, remove the datagridview and its
supporting table and dataset from the form and all comment out all the code
that I had written to use it. Then recreate the datagridview on the form,
reactivate the uncommented code before I can again try to use my form.
Am I missing something on how to make updates to a table and have these
reflected with a minimum of rework in the forms that. The behaviour that I
found will make it almost impossible to effectively modify an application
after its distributed. Any change would be a major undertaking.

I would appreciate any insights on how to make this process simpler.

Thanks,

Bob

[Cor Ligthert [MVP]]

Bob,

You did this probably never with the versions 2002/2003. Than you would know
what a pain was.

It is not yet there, however it becomes better. (in windowforms)

Cor

[Marina]

This is one of the reasons I think those design time tools are only really
good for learning. They seem to be more trouble then they are worth when
writing a real life application or application architecture.

"Bob" <bd*****@sgiims.com> wrote in message
news:ez**************@TK2MSFTNGP10.phx.gbl...

I found it a real pain working with the datasets and table adapters and
bound records. Here's why.
During development I find I occasionally have to change some part of a
table definition. Say I forgot to make the primary key an identity column
,yeah I'm human ;-). Typically I will find this out once the controls
using the erroneous table have been put on a form. I get the error
message, fine so far. Now I go into my sql server database and change the
defintion. I click on refresh for the dataset in the Vs data sources. Try
again, still same error. I found I have to remove the offending table from
the dataset defintion recreate the dataset definition, remove the
datagridview and its supporting table and dataset from the form and all
comment out all the code that I had written to use it. Then recreate the
datagridview on the form, reactivate the uncommented code before I can
again try to use my form.
Am I missing something on how to make updates to a table and have these
reflected with a minimum of rework in the forms that. The behaviour that I
found will make it almost impossible to effectively modify an application
after its distributed. Any change would be a major undertaking.

I would appreciate any insights on how to make this process simpler.

Thanks,

Bob

[guy]

so true:)

"Marina" wrote:

This is one of the reasons I think those design time tools are only really
good for learning. They seem to be more trouble then they are worth when
writing a real life application or application architecture.

"Bob" <bd*****@sgiims.com> wrote in message
news:ez**************@TK2MSFTNGP10.phx.gbl...

I found it a real pain working with the datasets and table adapters and
bound records. Here's why.
During development I find I occasionally have to change some part of a
table definition. Say I forgot to make the primary key an identity column
,yeah I'm human ;-). Typically I will find this out once the controls
using the erroneous table have been put on a form. I get the error
message, fine so far. Now I go into my sql server database and change the
defintion. I click on refresh for the dataset in the Vs data sources. Try
again, still same error. I found I have to remove the offending table from
the dataset defintion recreate the dataset definition, remove the
datagridview and its supporting table and dataset from the form and all
comment out all the code that I had written to use it. Then recreate the
datagridview on the form, reactivate the uncommented code before I can
again try to use my form.
Am I missing something on how to make updates to a table and have these
reflected with a minimum of rework in the forms that. The behaviour that I
found will make it almost impossible to effectively modify an application
after its distributed. Any change would be a major undertaking.

I would appreciate any insights on how to make this process simpler.

Thanks,

Bob

[Terry]

Yeh! What a pain. We all make those misteaks (=: These tools are next to
useless. This is my first .Net project & I thought it was me at first and
YES, I am using 2003. I gave them up very quickly. However the amount of code
you need has blown out. Development time has increased very significantly.
You get the feeling you are coding in a low level language rather than a,
supposedly, high level language.

"Bob" wrote:

I found it a real pain working with the datasets and table adapters and
bound records. Here's why.
During development I find I occasionally have to change some part of a table
definition. Say I forgot to make the primary key an identity column ,yeah
I'm human ;-). Typically I will find this out once the controls using the
erroneous table have been put on a form. I get the error message, fine so
far. Now I go into my sql server database and change the defintion. I click
on refresh for the dataset in the Vs data sources. Try again, still same
error. I found I have to remove the offending table from the dataset
defintion recreate the dataset definition, remove the datagridview and its
supporting table and dataset from the form and all comment out all the code
that I had written to use it. Then recreate the datagridview on the form,
reactivate the uncommented code before I can again try to use my form.
Am I missing something on how to make updates to a table and have these
reflected with a minimum of rework in the forms that. The behaviour that I
found will make it almost impossible to effectively modify an application
after its distributed. Any change would be a major undertaking.

I would appreciate any insights on how to make this process simpler.

Thanks,

Bob