I have created a new form project in VB 2008 express, and added a data-source 
pointing to a simple mdb file on my local hard drive at C:/DelMe (outside my 
project).

If I open the data using the database explorer (rather than the datasource 
explorer) and right click on a table and retrieve the data, then I can see 
the data and update it from within vb, and changes are actually made to the 
data in the mdb file.

However, if a create either a data grid or bound text boxes which use the 
datasource and then run the application, changes show up in the application 
and are seemingly made (ie the datasource is being correctly updated), but 
these changes are not propagated back to the mdb file.

In the datsource explorer, the tableadapter has both fill() and getdata() 
listed, and the sql for update seems fine (as it does for the select method 
which works correctly).

Why are the changes not being propagated back to the mdb file, and/or how 
can I 
debug this problem?

Thanks

When you incorporate the .MDB file in the project, it's copied to the Debug 
directory when the program enters debug mode. Change the File properties to 
indicate "copy if newer".

-- 
__________________________________________________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205  (Pacific time)
Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
____________________________________________________________________________________________

"Ycrl"  wrote in message 
news:C615D523-54DF-4F9D-9D57-6330F4B8EA85@microsoft.com...
> I have created a new form project in VB 2008 express, and added a 
> data-source
> pointing to a simple mdb file on my local hard drive at C:/DelMe (outside 
> my
> project).
>
> If I open the data using the database explorer (rather than the datasource
> explorer) and right click on a table and retrieve the data, then I can see
> the data and update it from within vb, and changes are actually made to 
> the
> data in the mdb file.
>
> However, if a create either a data grid or bound text boxes which use the
> datasource and then run the application, changes show up in the 
> application
> and are seemingly made (ie the datasource is being correctly updated), but
> these changes are not propagated back to the mdb file.
>
> In the datsource explorer, the tableadapter has both fill() and getdata()
> listed, and the sql for update seems fine (as it does for the select 
> method
> which works correctly).
>
> Why are the changes not being propagated back to the mdb file, and/or how
> can I
> debug this problem?
>
> Thanks
>

Dear William (Mr Vaughn),

No - the settings of the 'Copy to Output Directory' property of the .xsd 
DataSet in the Solutions Explorer window make no difference to the behaviour 
in either debug or Built mode (whether never copy/always copy/copy if newer) 
- the changes are not commited back to the mdb file.

And the mdb file was not incorporated into the project, it lies outside the 
project file structure elsewhere on the C: drive.

How, how, please help me, can I resolve or debug this problem.

Waiting for your kind answer.

With Thanks and Gratefulness for your help.


"William Vaughn [MVP]" wrote:

> When you incorporate the .MDB file in the project, it's copied to the Debug 
> directory when the program enters debug mode. Change the File properties to 
> indicate "copy if newer".
> 
> -- 
> __________________________________________________________________________
> William R. Vaughn
> President and Founder Beta V Corporation
> Author, Mentor, Dad, Grandpa
> Microsoft MVP
> (425) 556-9205  (Pacific time)
> Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
> ____________________________________________________________________________________________
> 
> "Ycrl"  wrote in message 
> news:C615D523-54DF-4F9D-9D57-6330F4B8EA85@microsoft.com...
> > I have created a new form project in VB 2008 express, and added a 
> > data-source
> > pointing to a simple mdb file on my local hard drive at C:/DelMe (outside 
> > my
> > project).
> >
> > If I open the data using the database explorer (rather than the datasource
> > explorer) and right click on a table and retrieve the data, then I can see
> > the data and update it from within vb, and changes are actually made to 
> > the
> > data in the mdb file.
> >
> > However, if a create either a data grid or bound text boxes which use the
> > datasource and then run the application, changes show up in the 
> > application
> > and are seemingly made (ie the datasource is being correctly updated), but
> > these changes are not propagated back to the mdb file.
> >
> > In the datsource explorer, the tableadapter has both fill() and getdata()
> > listed, and the sql for update seems fine (as it does for the select 
> > method
> > which works correctly).
> >
> > Why are the changes not being propagated back to the mdb file, and/or how
> > can I
> > debug this problem?
> >
> > Thanks
> >

So, since you're not using SQL Server you can't just  use the Profiler to 
see what's getting sent to the DBMS engine to process. This means you'll 
have to make sure that the JET engine (which I do not recommend for 
production applications) is responding correctly AND has enough time to 
process the operation. Consider that JET does not write to the database file 
immediately. It waits until it's bored (at idle time) to do so. This means 
that if you're disconnected from the engine (the application ends) before 
the writes are committed, the data can be lost. This can easily happen when 
there are a lot of operations to process. JET has no log so you can't easily 
recover when things go wrong. I could tell you how to solve the problem, but 
you won't like the answer. Switch to SQL Server Compact Edition or SQL 
Server Express (or better).

-- 
__________________________________________________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205  (Pacific time)
Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
____________________________________________________________________________________________

"Ycrl"  wrote in message 
news:0531D666-3D38-4CB4-A85F-1C2E99D78746@microsoft.com...
> Dear William (Mr Vaughn),
>
> No - the settings of the 'Copy to Output Directory' property of the .xsd
> DataSet in the Solutions Explorer window make no difference to the 
> behaviour
> in either debug or Built mode (whether never copy/always copy/copy if 
> newer)
> - the changes are not commited back to the mdb file.
>
> And the mdb file was not incorporated into the project, it lies outside 
> the
> project file structure elsewhere on the C: drive.
>
> How, how, please help me, can I resolve or debug this problem.
>
> Waiting for your kind answer.
>
> With Thanks and Gratefulness for your help.
>
>
> "William Vaughn [MVP]" wrote:
>
>> When you incorporate the .MDB file in the project, it's copied to the 
>> Debug
>> directory when the program enters debug mode. Change the File properties 
>> to
>> indicate "copy if newer".
>>
>> -- 
>> __________________________________________________________________________
>> William R. Vaughn
>> President and Founder Beta V Corporation
>> Author, Mentor, Dad, Grandpa
>> Microsoft MVP
>> (425) 556-9205  (Pacific time)
>> Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
>> ____________________________________________________________________________________________
>>
>> "Ycrl"  wrote in message
>> news:C615D523-54DF-4F9D-9D57-6330F4B8EA85@microsoft.com...
>> > I have created a new form project in VB 2008 express, and added a
>> > data-source
>> > pointing to a simple mdb file on my local hard drive at C:/DelMe 
>> > (outside
>> > my
>> > project).
>> >
>> > If I open the data using the database explorer (rather than the 
>> > datasource
>> > explorer) and right click on a table and retrieve the data, then I can 
>> > see
>> > the data and update it from within vb, and changes are actually made to
>> > the
>> > data in the mdb file.
>> >
>> > However, if a create either a data grid or bound text boxes which use 
>> > the
>> > datasource and then run the application, changes show up in the
>> > application
>> > and are seemingly made (ie the datasource is being correctly updated), 
>> > but
>> > these changes are not propagated back to the mdb file.
>> >
>> > In the datsource explorer, the tableadapter has both fill() and 
>> > getdata()
>> > listed, and the sql for update seems fine (as it does for the select
>> > method
>> > which works correctly).
>> >
>> > Why are the changes not being propagated back to the mdb file, and/or 
>> > how
>> > can I
>> > debug this problem?
>> >
>> > Thanks
>> >

But this cannot be an idle issue, as I have constructed a very simple one 
table example on a quiet hi-spec machine, and it never updates the mdb file, 
even after waiting several minutes.

Is this a permissions problem, or some other problem, or a bug ? When you 
create a simple mdb file outside the project, and create a data source to it 
and bound grid or controls to the data source, does your mdb file get updated 
?

How can I resolve this ?

Thanks for your comments about the limitability of mdb files with VB. I 
curse Microsoft for deprecating the technology, and take on board your 
comments that disconnected ADO.Net processing with Jet is not robust and 
should not be used. How dare Microsoft take this robust technology and 
deprecate it so badly when they had a connected version working so well years 
ago.

In my case I have to link to an mdb file, and I need to update the mdb file 
with VB. The data updates within VB, but does not update back to the mdb 
file. To repeat, if I use the view data right click from within the Database 
Explorer in VB then I can update the mdb file that way - but cannot obviously 
incorporate that into my project. Databound controls and grids are meant to 
be the RAD tool of choice.

How can I debug or resolve this ?

Any offers for help, or can anyone else replicate this simple problem (or 
does it work on your machine) ?

Thanks
------

"William Vaughn [MVP]" wrote:

> So, since you're not using SQL Server you can't just  use the Profiler to 
> see what's getting sent to the DBMS engine to process. This means you'll 
> have to make sure that the JET engine (which I do not recommend for 
> production applications) is responding correctly AND has enough time to 
> process the operation. Consider that JET does not write to the database file 
> immediately. It waits until it's bored (at idle time) to do so. This means 
> that if you're disconnected from the engine (the application ends) before 
> the writes are committed, the data can be lost. This can easily happen when 
> there are a lot of operations to process. JET has no log so you can't easily 
> recover when things go wrong. I could tell you how to solve the problem, but 
> you won't like the answer. Switch to SQL Server Compact Edition or SQL 
> Server Express (or better).
> 
> -- 
> __________________________________________________________________________
> William R. Vaughn
> President and Founder Beta V Corporation
> Author, Mentor, Dad, Grandpa
> Microsoft MVP
> (425) 556-9205  (Pacific time)
> Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)

With great thanks to Tim Anderson of PCW magazine in the UK, the data only 
gets sent back to the mdb file if you run the .update method of the relevant 
tableadapter !

This seems strange, as why has Microsoft gone to all the trouble of 
automating the Rapid Application Development (RAD) process of having bound 
controls and datagrids, whilst still requiring you to use code to commit the 
data ? A strange choice. But there it is.

"Ycrl" wrote:

> But this cannot be an idle issue, as I have constructed a very simple one 
> table example on a quiet hi-spec machine, and it never updates the mdb file, 
> even after waiting several minutes.
> 
> Is this a permissions problem, or some other problem, or a bug ? When you 
> create a simple mdb file outside the project, and create a data source to it 
> and bound grid or controls to the data source, does your mdb file get updated 
> ?
> 
> How can I resolve this ?
> 
> Thanks for your comments about the limitability of mdb files with VB. I 
> curse Microsoft for deprecating the technology, and take on board your 
> comments that disconnected ADO.Net processing with Jet is not robust and 
> should not be used. How dare Microsoft take this robust technology and 
> deprecate it so badly when they had a connected version working so well years 
> ago.
> 
> In my case I have to link to an mdb file, and I need to update the mdb file 
> with VB. The data updates within VB, but does not update back to the mdb 
> file. To repeat, if I use the view data right click from within the Database 
> Explorer in VB then I can update the mdb file that way - but cannot obviously 
> incorporate that into my project. Databound controls and grids are meant to 
> be the RAD tool of choice.
> 
> How can I debug or resolve this ?
> 
> Any offers for help, or can anyone else replicate this simple problem (or 
> does it work on your machine) ?
> 
> Thanks
> ------
> 
> "William Vaughn [MVP]" wrote:
> 
> > So, since you're not using SQL Server you can't just  use the Profiler to 
> > see what's getting sent to the DBMS engine to process. This means you'll 
> > have to make sure that the JET engine (which I do not recommend for 
> > production applications) is responding correctly AND has enough time to 
> > process the operation. Consider that JET does not write to the database file 
> > immediately. It waits until it's bored (at idle time) to do so. This means 
> > that if you're disconnected from the engine (the application ends) before 
> > the writes are committed, the data can be lost. This can easily happen when 
> > there are a lot of operations to process. JET has no log so you can't easily 
> > recover when things go wrong. I could tell you how to solve the problem, but 
> > you won't like the answer. Switch to SQL Server Compact Edition or SQL 
> > Server Express (or better).
> > 
> > -- 
> > __________________________________________________________________________
> > William R. Vaughn
> > President and Founder Beta V Corporation
> > Author, Mentor, Dad, Grandpa
> > Microsoft MVP
> > (425) 556-9205  (Pacific time)
> > Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)

It does not seem strange at all to me. So, you've made a change in the grid 
and you don't want it committed until you've made several other changes. If 
it did it automatically, you would be in trouble. Isolating the Update 
operation also lets you put exception handlers around the code to make sure 
that the stuff that happens during an UPDATE operation are caught and dealt 
with. RAD or not, it's always worked this way.

"Ycrl"  wrote in message 
news:94009F7D-9083-49E1-A2B0-6A767F7E566D@microsoft.com...
> With great thanks to Tim Anderson of PCW magazine in the UK, the data only
> gets sent back to the mdb file if you run the .update method of the 
> relevant
> tableadapter !
>
> This seems strange, as why has Microsoft gone to all the trouble of
> automating the Rapid Application Development (RAD) process of having bound
> controls and datagrids, whilst still requiring you to use code to commit 
> the
> data ? A strange choice. But there it is.
>
> "Ycrl" wrote:
>
>> But this cannot be an idle issue, as I have constructed a very simple one
>> table example on a quiet hi-spec machine, and it never updates the mdb 
>> file,
>> even after waiting several minutes.
>>
>> Is this a permissions problem, or some other problem, or a bug ? When you
>> create a simple mdb file outside the project, and create a data source to 
>> it
>> and bound grid or controls to the data source, does your mdb file get 
>> updated
>> ?
>>
>> How can I resolve this ?
>>
>> Thanks for your comments about the limitability of mdb files with VB. I
>> curse Microsoft for deprecating the technology, and take on board your
>> comments that disconnected ADO.Net processing with Jet is not robust and
>> should not be used. How dare Microsoft take this robust technology and
>> deprecate it so badly when they had a connected version working so well 
>> years
>> ago.
>>
>> In my case I have to link to an mdb file, and I need to update the mdb 
>> file
>> with VB. The data updates within VB, but does not update back to the mdb
>> file. To repeat, if I use the view data right click from within the 
>> Database
>> Explorer in VB then I can update the mdb file that way - but cannot 
>> obviously
>> incorporate that into my project. Databound controls and grids are meant 
>> to
>> be the RAD tool of choice.
>>
>> How can I debug or resolve this ?
>>
>> Any offers for help, or can anyone else replicate this simple problem (or
>> does it work on your machine) ?
>>
>> Thanks
>> ------
>>
>> "William Vaughn [MVP]" wrote:
>>
>> > So, since you're not using SQL Server you can't just  use the Profiler 
>> > to
>> > see what's getting sent to the DBMS engine to process. This means 
>> > you'll
>> > have to make sure that the JET engine (which I do not recommend for
>> > production applications) is responding correctly AND has enough time to
>> > process the operation. Consider that JET does not write to the database 
>> > file
>> > immediately. It waits until it's bored (at idle time) to do so. This 
>> > means
>> > that if you're disconnected from the engine (the application ends) 
>> > before
>> > the writes are committed, the data can be lost. This can easily happen 
>> > when
>> > there are a lot of operations to process. JET has no log so you can't 
>> > easily
>> > recover when things go wrong. I could tell you how to solve the 
>> > problem, but
>> > you won't like the answer. Switch to SQL Server Compact Edition or SQL
>> > Server Express (or better).
>> >
>> > -- 
>> > __________________________________________________________________________
>> > William R. Vaughn
>> > President and Founder Beta V Corporation
>> > Author, Mentor, Dad, Grandpa
>> > Microsoft MVP
>> > (425) 556-9205  (Pacific time)
>> > Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)

-- 
__________________________________________________________________________
William R. Vaughn
President and Founder Beta V Corporation
Author, Mentor, Dad, Grandpa
Microsoft MVP
(425) 556-9205  (Pacific time)
Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
____________________________________________________________________________________________

It's just that I come from a Microsoft Access background where the opposite 
approach is taken.
With Access, all the data checks you talk about can be made if you wish, as 
all you have to do is write code for the various appropriate events prior to 
data committal.
If you write no code, Access automatically commits the changed data.

From a RAD point of view, this approach (which has equal flexibility and 
utility to VB's) is obviously better as no extra code is required !

"William Vaughn (MVP)" wrote:

> It does not seem strange at all to me. So, you've made a change in the grid 
> and you don't want it committed until you've made several other changes. If 
> it did it automatically, you would be in trouble. Isolating the Update 
> operation also lets you put exception handlers around the code to make sure 
> that the stuff that happens during an UPDATE operation are caught and dealt 
> with. RAD or not, it's always worked this way.
> 
> "Ycrl"  wrote in message 
> news:94009F7D-9083-49E1-A2B0-6A767F7E566D@microsoft.com...
> > With great thanks to Tim Anderson of PCW magazine in the UK, the data only
> > gets sent back to the mdb file if you run the .update method of the 
> > relevant
> > tableadapter !
> >
> > This seems strange, as why has Microsoft gone to all the trouble of
> > automating the Rapid Application Development (RAD) process of having bound
> > controls and datagrids, whilst still requiring you to use code to commit 
> > the
> > data ? A strange choice. But there it is.
> >
> > "Ycrl" wrote:
> >
> >> But this cannot be an idle issue, as I have constructed a very simple one
> >> table example on a quiet hi-spec machine, and it never updates the mdb 
> >> file,
> >> even after waiting several minutes.
> >>
> >> Is this a permissions problem, or some other problem, or a bug ? When you
> >> create a simple mdb file outside the project, and create a data source to 
> >> it
> >> and bound grid or controls to the data source, does your mdb file get 
> >> updated
> >> ?
> >>
> >> How can I resolve this ?
> >>
> >> Thanks for your comments about the limitability of mdb files with VB. I
> >> curse Microsoft for deprecating the technology, and take on board your
> >> comments that disconnected ADO.Net processing with Jet is not robust and
> >> should not be used. How dare Microsoft take this robust technology and
> >> deprecate it so badly when they had a connected version working so well 
> >> years
> >> ago.
> >>
> >> In my case I have to link to an mdb file, and I need to update the mdb 
> >> file
> >> with VB. The data updates within VB, but does not update back to the mdb
> >> file. To repeat, if I use the view data right click from within the 
> >> Database
> >> Explorer in VB then I can update the mdb file that way - but cannot 
> >> obviously
> >> incorporate that into my project. Databound controls and grids are meant 
> >> to
> >> be the RAD tool of choice.
> >>
> >> How can I debug or resolve this ?
> >>
> >> Any offers for help, or can anyone else replicate this simple problem (or
> >> does it work on your machine) ?
> >>
> >> Thanks
> >> ------
> >>
> >> "William Vaughn [MVP]" wrote:
> >>
> >> > So, since you're not using SQL Server you can't just  use the Profiler 
> >> > to
> >> > see what's getting sent to the DBMS engine to process. This means 
> >> > you'll
> >> > have to make sure that the JET engine (which I do not recommend for
> >> > production applications) is responding correctly AND has enough time to
> >> > process the operation. Consider that JET does not write to the database 
> >> > file
> >> > immediately. It waits until it's bored (at idle time) to do so. This 
> >> > means
> >> > that if you're disconnected from the engine (the application ends) 
> >> > before
> >> > the writes are committed, the data can be lost. This can easily happen 
> >> > when
> >> > there are a lot of operations to process. JET has no log so you can't 
> >> > easily
> >> > recover when things go wrong. I could tell you how to solve the 
> >> > problem, but
> >> > you won't like the answer. Switch to SQL Server Compact Edition or SQL
> >> > Server Express (or better).
> >> >
> >> > -- 
> >> > __________________________________________________________________________
> >> > William R. Vaughn
> >> > President and Founder Beta V Corporation
> >> > Author, Mentor, Dad, Grandpa
> >> > Microsoft MVP
> >> > (425) 556-9205  (Pacific time)
> >> > Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
> 
> -- 
> __________________________________________________________________________
> William R. Vaughn
> President and Founder Beta V Corporation
> Author, Mentor, Dad, Grandpa
> Microsoft MVP
> (425) 556-9205  (Pacific time)
> Hitchhiker’s Guide to Visual Studio and SQL Server (7th Edition)
> ____________________________________________________________________________________________
> 
>  
>

On Tue, 8 Jul 2008 10:32:04 -0700, Ycrl  wrote:

¤ It's just that I come from a Microsoft Access background where the opposite 
¤ approach is taken.
¤ With Access, all the data checks you talk about can be made if you wish, as 
¤ all you have to do is write code for the various appropriate events prior to 
¤ data committal.
¤ If you write no code, Access automatically commits the changed data.
¤ 
¤ From a RAD point of view, this approach (which has equal flexibility and 
¤ utility to VB's) is obviously better as no extra code is required !
¤ 

Well yes, but unfortunately Access doesn't provide you with as many options or much flexibility once
you try to customize. It was better than Classic VB's data control features but you're essentially
locked into the UI they provide.

However, I agree that the .NET UI should at least display a popup or something when you select the
data source for your UI control, which would indicate that you need to supply the update
functionality.


Paul
~~~~
Microsoft MVP (Visual Basic)

Many thanks for your thoughts. I appreciate and value your opinion.

It is just that having actually used Access as a killer RAD tool, and having 
successfully sold a few companies to large blue-chip multinationals because 
they liked the Access-built software so much and believed it was industry 
changing in each company's sector, I happen to disagree (justifiably ?) with 
the crowd. 

Access has pretty-much equivalent flexibility to vb (how many things can you 
do easily in vb that you can't in Access ? - are there any important ones - I 
don't think so ?), but Access uses a connected database model where VB uses a 
disconnected model.

In the real business world, this difference is critical, as Access becomes 
quick and efficient, and VB is great except for conflict resolution, but 
conflict resolution takes so much time and programming that it can often 
destroy the RAD'ness of an application and set a project back.

Locking a row in a database is so fundamental to business programming, and 
Access handles this with ease. VB is disconnected, so can't. Oh, why have 
Microsoft deprecated Access !?!

"Paul Clement" wrote:

> On Tue, 8 Jul 2008 10:32:04 -0700, Ycrl  wrote:
> 
> ¤ It's just that I come from a Microsoft Access background where the opposite 
> ¤ approach is taken.
> ¤ With Access, all the data checks you talk about can be made if you wish, as 
> ¤ all you have to do is write code for the various appropriate events prior to 
> ¤ data committal.
> ¤ If you write no code, Access automatically commits the changed data.
> ¤ 
> ¤ From a RAD point of view, this approach (which has equal flexibility and 
> ¤ utility to VB's) is obviously better as no extra code is required !
> ¤ 
> 
> Well yes, but unfortunately Access doesn't provide you with as many options or much flexibility once
> you try to customize. It was better than Classic VB's data control features but you're essentially
> locked into the UI they provide.
> 
> However, I agree that the .NET UI should at least display a popup or something when you select the
> data source for your UI control, which would indicate that you need to supply the update
> functionality.
> 
> 
> Paul
> ~~~~
> Microsoft MVP (Visual Basic)
>