In fact the entire approach (datasets, table adapters, table adapter managers, bindingsources, bindingnavigators, etc.) seems creaky and brittle, ad hoc, and in places incomplete. Usually I have to delete the dataset, reimport it, then by hand reestablish all of the relations in the database. But I'm deeply suspicious that any changes to the dataset aren't reflected in the autogenerated code - I've seen something like this before when trying to accomodate a new MS Access table by augmenting the dataset. My new approach would be to create a second tableadapter with the parameterized query I can't imagine that that would break the original tableadapter. It is time, I think, to lose a few days work and go to an old backup. I've been working through various autogenerated files, looking at what might have gone wrong with Ainfo it is by no means obvious. OK, clearly there is something going on here I don't understand so I removed my new query, and I still get the error. By adding a second query to the Ainfo tableadapter I seem to have broken the original. Now, however, a call to the tableadapter Ainfo.update(.) is marked as an error, that 'update is not a member of Ainfo'. I managed to work through the Query Builder and things seemed ok. For one of the tableadapters in the dataset (let me call this Ainfo) I wanted to add a second FILL query, one that would take parameters to show a subset of the data. I have a fairly large VB.net system which talks to an underlying MS Access database until recently all was working well.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |