Do linq to sql queries behave properly in user controls? RRS feed

  • Question

  • Good morning everyone,
    I'm having an issue with a user control I'm developing for an application.  I have two projects in the same solution.  One is the application and the other is the usercontrol.  The user control consists of a couple textboxes and a couple combo boxes.  It's purpose is to serve as the individual elements in a homespun data repeater-like control (the application) that permits the user to add and delete lines of items. 

    I have a linq to sql query that retrieves the values from a database table and uses that data to populate the list in a combo box.  This behaves as expected with the following exception: 

    Elsewhere in the application, the user is able to manage the database via a homespun form.  This form is not bound to the database.   Using linq to sql, the database is appended with new items that should be available to the usercontrol's combo box, but they aren't.  Adding the usercontrol to the form AFTER the database is appended doesn't help.  Using a linq to sql query elsewhere in the application, I'm able to confirm the database was indeed updated.  What would prevent the user control from retrieving current data from the table?  It's as if the usercontrol is querying the database at startup and disregards any changes to the table after that.  I'm relatively new to VB.NET and even newer to LINQ.  I'd be happy to post some of the code if anyone thinks that may help. 



    Monday, May 4, 2009 11:56 AM

All replies

  • Since the control is bound with the data from the original call, you need to manually rebind with a new call it after a change on the other form. There is no triggering event done with Linq to inform any consumers of the data that new data exists. HTH GL
    William Wegerson (www.OmegaCoder.Com)
    Monday, May 4, 2009 6:55 PM
  • Thanks Omega...
    Maybe I don't understand the definition of a call?  If I create a new instance of the control *after* making changes to the database, isn't that considered a new call?

    If that isn't considered a "new call", then how do I go about creating one?

    Tuesday, May 5, 2009 12:47 PM
  • If the data has been submitted to the database via SubmitChanges() and directly after that the control is bound to the target table that had the changes, then yes it should show the changes. The question is, when is the data being bound?

    William Wegerson (www.OmegaCoder.Com)
    Tuesday, May 5, 2009 2:29 PM
  • The data isn't bound to the control, per se.  A procedure within the control performs a linqtosql CRUD query to fetch all the fields in a table... and yes, this is happening on instantiation of the control AFTER the SubmitChanges() occurs in a CRUD operation on the application side.   It makes no sense to me.

    I found a work around using essentially the same code... I have the application do the crud op and send the results to a usercontrol method which populates a listbox with the results.  Not as clean as I like, but it works.

    Wednesday, May 6, 2009 1:13 PM
  • Could you post the parts of the code for the user control that are relevant to the problem? I have some initial hunches (like the query in the user control is done inside of a static initializer, so it would never refresh), but I'd like to look at the code to see other alternatives.
    Sunday, May 10, 2009 4:46 PM