ListView Requery After Delete Operation
 
Home My Account Forum Try It! Buy It!
About Contact Us Site Map
StrataFrame Forum
Home      Members   Calendar   Who's On
Welcome Guest ( Login | Register )
      



ListView Requery After Delete OperationExpand / Collapse
Author
Message
Posted 02/25/2008 3:45:17 PM
StrataFrame User

StrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame User

Group: StrataFrame Users
Last Login: 2 days ago @ 6:32:47 PM
Posts: 349, Visits: 1,205
I have a ListView that is getting populated on a requery.  I am passing in the ListPopulating method (as recommended) one of the business objects on the form along with the BusinessCloneDataType.  This is working great.  Whereever I need to call the requery method of the ListView, I no longer care about parameters...I just call it.

After a user deletes a record successfully, I thought it would be a good idea to call that requery method.  So, after checking success on the delete and the save events, I call the requery method of the ListView.  The resulting list is wrong.  An entirely different customer is being displayed in the list (the customer comes from a call (PopulatedThroughEvent) in the RowPopulating event).  If I navigate away from the main BO and come back, the ListView shows the correct customer.  If I add a new record and call the requery method, the ListView show the proper customer.  Only the delete is doing this.  So, what am I doing wrong?

Thanks!
Bill

Post #14543
Posted 02/25/2008 4:15:28 PM


StrataFrame Developer

StrataFrame Developer

Group: StrataFrame Developers
Last Login: Today @ 11:54:01 AM
Posts: 4,104, Visits: 4,177
If I navigate away from the main BO and come back, the ListView shows the correct customer.  If I add a new record and call the requery method, the ListView show the proper customer.  Only the delete is doing this.  So, what am I doing wrong?

I assume that you are deleting the parent record.  The BOs do not cascade the deletions to the child (by default).  You need to clear out the child BO records that are no longer valid by either repopulating the BO, or clearing it out via the Clear method.  Or...delete each of the records that are no longer valid.  More than likely the cascading deletes have taken place on the server, so you just need to clear out the child BO to match the parent.  I recommend doing this manually instead of allowing the deletions or child records to be automatically filtered (other issues that arise from there )

MyBo.Clear()

or


'-- Delete all of the records that need to be deleted (this code would only delete a single record)
MyBo.DeleteCurrentRow(True)


'-- Update the BO so that it doesn't reflect any dirty changes.  By doing this, you can make a change
'   to the BO data and prevent it from trying to persist back to the server.  Once called, the BO will no longer be in a
'   dirty state.
MyBo.CurrentDataTable.AcceptChanges()

Post #14544
Posted 02/25/2008 5:48:00 PM
StrataFrame User

StrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame User

Group: StrataFrame Users
Last Login: 2 days ago @ 6:32:47 PM
Posts: 349, Visits: 1,205
Nope...not deleting the parent, just a child.  What I did to get around the problem was to explicitly refill the child BO.  That seems to have done the trick.  Thanks for the help!

Bill

Post #14546
Posted 02/25/2008 9:48:02 PM


StrataFrame Developer

StrataFrame Developer

Group: StrataFrame Developers
Last Login: Today @ 11:54:01 AM
Posts: 4,104, Visits: 4,177
Nope...not deleting the parent, just a child.  What I did to get around the problem was to explicitly refill the child BO.  That seems to have done the trick. 

That would work, but it is requireing another trip to the server.  I think that you probably called the DeletePrimarykey method instead of the DeleteCurrentRow.  The DeletePrimarykey method just "smokes" it from the server and doesn't update the BO.  However, the DeleteCurrentRow updates the internal data as well as the server, if you call it with a False, otherwise a Save must happen to commit the deleted record.

Post #14549
Posted 02/26/2008 11:25:51 AM
StrataFrame User

StrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame UserStrataFrame User

Group: StrataFrame Users
Last Login: 2 days ago @ 6:32:47 PM
Posts: 349, Visits: 1,205
I was calling DeleteCurrentRow() without a parameter.  I was forced to add the Save() function to get things going, so I used your tactic, instead.  I am now calling DeleteCurrentRow(false).  No need to call Save(), anymore.  Also, in order to get around another issue that I was having I added another temporary BO into the mix so that the ListView would populate properly.  In the RowPopulating event I setup a new BO to reference the BO of the ListView, then I grabbed the foreign key index from the BO and retrieved the field I needed from the customer BO to fill in the name.

It is all quite simple after I worked it all out.  Took a little while.  The goal was to be able to see a list of items, select one, and provide add/edit/delete capabilities in the same window.  I attached an example of what I did.

Thanks for your help!  Have a great day!!
Bill

  Post Attachments 
example.JPG (15 views, 49.16 KB)

Post #14553
Posted 02/26/2008 12:45:42 PM


StrataFrame Developer

StrataFrame Developer

Group: StrataFrame Developers
Last Login: Today @ 11:54:01 AM
Posts: 4,104, Visits: 4,177
Looks good, Bill!
Post #14555
« Prev Topic | Next Topic »


Reading This TopicExpand / Collapse
Active Users: 0 (0 guests, 0 members, 0 anonymous members)
No members currently viewing this topic.
Forum Moderators: Ben Chase, Trent L. Taylor, Steve L. Taylor

PermissionsExpand / Collapse

All times are GMT -6:00, Time now is 7:31pm

Powered By InstantForum.NET v4.1.4 © 2008
Execution: 0.141. 11 queries. Compression Enabled.
Site Map - Home - My Account - Forum - About Us - Contact Us - Try It - Buy It

Microsoft, Visual Studio, and the Visual Studio logo are trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.