PHP User Warning: fetch_template() calls should be replaced by the vB_Template class. Template name: bbcode_highlight in ..../includes/functions.php on line 4197
[RESOLVED] End Edit/Update-VBForums
Results 1 to 15 of 15

Thread: [RESOLVED] End Edit/Update

  1. #1

    Thread Starter
    Hyperactive Member
    Join Date
    Dec 2011
    Location
    Oregon City, Oregon
    Posts
    471

    Resolved [RESOLVED] End Edit/Update

    This is something that has been on my mind for awhile. It is the kind of thing that I should be able to look up in what apparently is a now defunct knowledge base. Most of what I am doing is tied into databases (usually Access, but not all the time as I also like working in SQL)

    I long ago learned that when working with datasets you are one step removed from the actual database. So updating the database is a two step process, as I understand it. There is the TableBindingSource.EndEdit() and the TableAdapter.Update(Dataset) So here is my understanding and I would like to know if I am even in the ball park.

    I have a form filled with controls, all of which are databound. I fill the controls with data. Now when I run the EndEdit() command line that locks the data into the tableadapter. When I run the Update() command line that saves the data to the database table and makes it permanent. Is this even in the ballpark?

    I have a habit of moving around between forms quite a bit. So, can I leave that form and come back to it without running EndEdit() and Update() and the data still be held in the form controls? If I leave the form after running an EndEdit() can I re-query the tableadapter and expect the data still be there? If I am entering data to a table on a form run the EndEdit() can I re-query that table from another form (assuming the other form has a tableadapter and binding source for that table) and run the update() from this other form.

    Now it is my belief that I should be able to do all of that, but I would like to know for sure prior to investing a lot of time working on those assumptions.

  2. #2
    Hyperactive Member Mike Storm's Avatar
    Join Date
    Jun 2017
    Location
    Belgium
    Posts
    425

    Re: End Edit/Update

    Hi,
    EndEdit commits data to the table adapter
    Update() commits data to the database

    Assuming you refering to the DataAdapters automaticly created by the designer for you when you drag the table in to you form, each adapter is a new instance of it self, means they independent, one does not know what you did in the other.
    So you can move from one form to the other and since you dont close or dispose of them without Validate(), EndEdit() and Update(Dtaset) you ont louse changes, but also does changes are not reflected on one another.

  3. #3

    Thread Starter
    Hyperactive Member
    Join Date
    Dec 2011
    Location
    Oregon City, Oregon
    Posts
    471

    Re: End Edit/Update

    If I understand this correctly, this is a real disappointment. So lets say I do this in one form:

    Code:
            Me.tblChangeApproveBindingSource.AddNew()
            CType(Me.tblChangeApproveBindingSource.Current, DataRowView).Item("intChangeID") = glbintCRNum
            CType(Me.tblChangeApproveBindingSource.Current, DataRowView).Item("strName") = CType(TblEmployeeBindingSource.Current, DataRowView).Item("strFullName")
    By the way, you should remember this, since it was you who showed it to me. So then right after that I move to a different for, which I have placed the table adapter and binding source for tblChangeApprove and run the following:

    Code:
            Me.Validate()
            Me.tblChangeApproveBindingSource.EndEdit()
            Me.TblChangeApproveTableAdapter.Update(Me._MasterBase4_0ItemMasterDataSet)
    You are then saying that the save would not occur because they are different instances?

  4. #4

    Thread Starter
    Hyperactive Member
    Join Date
    Dec 2011
    Location
    Oregon City, Oregon
    Posts
    471

    Re: End Edit/Update

    Crap, I already answered my own question. Because they are different instances you get not benefit from them in from one form to another. I have been hosed before on the word instance. Life really sucks sometimes.

  5. #5
    Hyperactive Member Mike Storm's Avatar
    Join Date
    Jun 2017
    Location
    Belgium
    Posts
    425

    Re: [RESOLVED] End Edit/Update

    Lets say:

    Form A has the tableadapter: tblChangeApproveTableAdapter its named Aproved_FORM and tblChangeApproveBindingSource is binded to tblChangeApproveTableAdapter

    Form B has the tableadapter: TblEmployeeTableAdapter its named Employes_FORM

    and you call Employes_FORM from Aproved_FORM and under event CellDoubleClick of the datagridview on Employes_FORM you add the code:

    Code:
           CType(Aproved_FORM.tblChangeApproveBindingSource.Current, DataRowView).Item("strName") = CType(TblEmployeeBindingSource.Current, DataRowView).Item("strFullName")
            Aproved_FORM.Validate()
            Aproved_FORM.tblChangeApproveBindingSource.EndEdit()
            Aproved_FORM.TblChangeApproveTableAdapter.Update(Me._MasterBase4_0ItemMasterDataSet)
    Yes, changes will reflect on Aproved_FORM dataadapter.
    Last edited by Mike Storm; Sep 30th, 2017 at 01:38 PM.

  6. #6
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    104,153

    Re: [RESOLVED] End Edit/Update

    A table adapter doesn't contain any data. A table adapter contains four commands which each refer to the same connection object. When you call Fill, the connection is opened, the SelectedCommand is executed and data is retrieved and stored in a DataTable. When you call Update, the connection is opened, the InsertCommand is executed for each DataRow with a RowState of Added, the UpdateCommand is executed for each Modified row and the DeleteCommand is executed for each Deleted row and the changes saved to the database. The data is stored locally in the DataTable and the table adapter is simply about executing SQL to move data between the database and that DataTable.

    The EndEdit method is about committing the most recent change to the DataTable. If you call AddNew on the BindingSource then that creates a new DataRow with a RowState of Detached. Calling EndEdit in that case will actually add that row to the DataTable, changing its RowState to Added. Editing a DataRow directly may or may not require a call to EndEdit. If BeginEdit was called first, which is done implicitly when editing via the bound UI, then EndEdit is required. If you start editing another record then EndEdit is called implicitly on the previous one, so it's only the last edit that you need to commit explicitly. If you edit a DataRow directly in code then there's no need to call BeginEdit and thus no need to call EndEdit.

    The idea of dragging a DataTable onto a form in the designer is so that you can configure data-binding in the designer but you don't have to do that. If you want to share data between forms then go ahead and share data. For instance, if you drag a DataTable onto Form1 in the designer and then Form1 creates an instance of Form2 and you want to share data between them, you can simply code it so that Form1 passes a DataTable to Form2 when it creates it. In that case, you won't be able to configure data-binding on Form2 in the designer but you can certainly do it in code. For instance, you might write a constructor in Form2 that has a DataTable parameter so that an instance can't be created without providing a DataTable and then bind it in code:
    vb.net Code:
    1. Public Class Form2
    2.  
    3.     Public Sub New(table As DataTable)
    4.         ' This call is required by the designer.
    5.         InitializeComponent()
    6.  
    7.         ' Add any initialization after the InitializeComponent() call.
    8.  
    9.         BindingSource1.DataSource = table
    10.         DataGridView1.DataSource = BindingSource1
    11.     End Sub
    12.  
    13. End Class
    You'd still add the DataGridView and the BindingSource in the designer. In that case, there's only one DataTable so any changes made on either form will be reflected in the other.

  7. #7

    Thread Starter
    Hyperactive Member
    Join Date
    Dec 2011
    Location
    Oregon City, Oregon
    Posts
    471

    Re: [RESOLVED] End Edit/Update

    JM, That sounds like something I would be very interested in. It almost sounds like you are dispensing with the use of a dataset and table adapters. I have a hard time believing that it can be that easy. Do you have any additional information on this approach?

  8. #8
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    104,153

    Re: [RESOLVED] End Edit/Update

    Quote Originally Posted by gwboolean View Post
    It almost sounds like you are dispensing with the use of a dataset and table adapters.
    I'm not suggesting that at all. the DataSet and table adapter(s) still play exactly the same roles as before. The only difference is that they are only added in the designer for one form. Rather than the second form having its own DataSet and table adapters added via the designer, it receives a DataSet (or part of a DataSet, i.e. a DataTable) from the first form. The second form doesn't need any table adapters because all the retrieving and saving of data is done on the first form. That said, the second form could still have its own table adapter(s) and do its own saving if you wanted to. The main thing is that there is only one DataSet between the forms and thus any changes made in either one will be reflected in the other.

  9. #9

    Thread Starter
    Hyperactive Member
    Join Date
    Dec 2011
    Location
    Oregon City, Oregon
    Posts
    471

    Re: [RESOLVED] End Edit/Update

    Thanks JM. That provides clarity. Still, I think that eventually I am going to move towards direct interaction with the DB instead of the use of datasets. But that is the future and this is now and I will be implementing your ideas.

  10. #10
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    104,153

    Re: [RESOLVED] End Edit/Update

    Quote Originally Posted by gwboolean View Post
    I think that eventually I am going to move towards direct interaction with the DB instead of the use of datasets.
    Then you think wrong. You can use ADO.NET with or without a typed DataSet or you can use Entity Framework or LINQ to SQL but you're not interacting directly with the database in any case. They are all disconnected, i.e. you open a connection, retrieve data and cache it locally, work against that local copy, open the connection again and save the changes. To do as you suggest, you'd have to regress back to ADO, which you should absolutely not do.

  11. #11

    Thread Starter
    Hyperactive Member
    Join Date
    Dec 2011
    Location
    Oregon City, Oregon
    Posts
    471

    Re: [RESOLVED] End Edit/Update

    Actually, I do not think wrong. I have been going through some material that I obtained from Karen (your moderator) and it is quite doable. Not easy mind you, but quite doable.

  12. #12
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    104,153

    Re: [RESOLVED] End Edit/Update

    Why would you?

  13. #13

    Thread Starter
    Hyperactive Member
    Join Date
    Dec 2011
    Location
    Oregon City, Oregon
    Posts
    471

    Re: [RESOLVED] End Edit/Update

    There you ask a good question JM. So why would anyone do something different when what they are doing is working seemingly well? (I paraphrased). There is no rational answer to that except possibly that things are going too well and need some shaking up. You can decide whether that is rational or not. However, I have not completely convinced myself that I will do it. I am merely thinking about it.

  14. #14
    .NUT jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    104,153

    Re: [RESOLVED] End Edit/Update

    Obviously what you do is up to you but I would suggest that you be almost certainly wasting your time. There's nothing wrong with doing obscure things for interest's sake but I'd suggest that there would be plenty of useful things that you could spend your time learning that would also be interesting. There would undoubtedly be some legitimate uses for such data access but I've been working with VB.NET for 14 years and not encountered one.

  15. #15

    Thread Starter
    Hyperactive Member
    Join Date
    Dec 2011
    Location
    Oregon City, Oregon
    Posts
    471

    Re: [RESOLVED] End Edit/Update

    True. I probably won't do anything with that. But I will take a good long look at it. I just don't know when. As you said, there are plenty of useful things to spend time on. I will add that you have to choose which ones add the most value and I am not convinced that this is one of those.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width