 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
VB Forum / Controls / July 2008Help Needed - Please
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 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. > 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 [quoted text clipped - 19 lines] > > Thanks > 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 [quoted text clipped - 4 lines] > controls and datagrids, whilst still requiring you to use code to commit the > data ? A strange choice. But there it is. Not really as the under-lying model has changed. Previous access libraries defaulted to "connected", now the default in the dotNet world is for "dis-connected" recordsets. That fact is pointed out quite clearly early on within the ADO.Net documentation, but "why" it is going to make a difference, MS leaves as an exercise for the developer to stubble across. <g> -ralph 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 as you point out, 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 !?! > > 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 [quoted text clipped - 16 lines] > > -ralph > Many thanks for your thoughts. I appreciate and value your opinion. > [quoted text clipped - 17 lines] > Access handles this with ease. VB is disconnected, so can't. Oh, why have > Microsoft deprecated Access !?! <snipped> I agree with your comments, but would like to make it clear for anyone else following this thread that where you mention "VB", you are actually referring to "VB.Net" (and VSTO by extension). The reasons developers flock to newer technologies are obvious, but I have never understood the 'vilification' of the technologies they left behind, especially when those technologies still 'work' for their designed purpose. A disconnected data server engine makes sense for massive distributed information systems, but very little sense for more modest requirements. Why MS has this desire to kill off everything before??? I haven't a clue - only a suspicion - "Ballmer". -ralph |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.