locked
Problem with ObjectDataSource and Strongly Typed Datasets RRS feed

  • Question

  • User1520651007 posted
    • I have the following tiers set up:
      a DB I/O tier for DB calls
      a Strongly Typed Dataset tier which contains the datasets. Any project can now access these datasets simply by creating a reference to it. This project has the previous project as a reference.
      a Business Tier which has my methods for selecting & updating data. This has the previous two projects set as a reference.
      a Presentation Tier which has the previous 3 projects as a reference.


    The problem I'm having is that when I try to view the page in the browser, the following error comes back:
    "Procedure 'usp_SelectCustomers' expects parameter '@Country', which was not supplied".

    My Business Tier has the following two methods in it:
    <code>
    Public Function SelectCustomers(ByVal strCountry As String) As dstCustomers

    Dim dst As New dstCustomers

    Try

    SQLServerDataAccess.GetSQLData(SqlConnection1, SqlDataAdapter1, dst)

    Catch ex As Exception

    Throw ex

    Finally

    SqlDataAdapter1.Dispose()

    If SqlConnection1.State = ConnectionState.Open Then

    SqlConnection1.Close()

    End If

    End Try

    Return dst

    End Function



    Public
    Function UpdateCustomers(ByVal dst As dstCustomers) As Integer

    Try

    SQLServerDataAccess.ExecuteSQLNonQuery(SqlConnection1, SqlDataAdapter1, dst)

    Catch ex As Exception

    Throw ex

    Finally

    SqlDataAdapter1.Dispose()

    If SqlConnection1.State = ConnectionState.Open Then

    SqlConnection1.Close()

    End If

    End Try

    End Function
    </code>

    You can see that I have the parameter set up correctly in the Select method.

    I have the following HTML in my source view of the presentation page:
    <code>

    <asp:GridView ID="GridView1" runat="server" AllowPaging="True" AllowSorting="True"

    AutoGenerateColumns="False" CellPadding="4" DataKeyNames="CustomerID" DataSourceID="ObjectDataSource1"

    ForeColor="#333333" GridLines="None">

    .
    .
    .

    <asp:ObjectDataSource ID="ObjectDataSource1" runat="server" DataObjectTypeName="StronglyTypedDataSets.dstCustomers"

    DeleteMethod="UpdateCustomers" InsertMethod="UpdateCustomers" SelectMethod="SelectCustomers"

    TypeName="BusinessLayer.Component1" UpdateMethod="UpdateCustomers">

    <SelectParameters>

    <asp:ControlParameter ControlID="TextBox1" DefaultValue="USA" Name="strCountry" PropertyName="Text"

    Type="String" />

    </SelectParameters>

    </asp:ObjectDataSource>
    </code>


    You can see where I have the DefaultValue set up as "USA". I don't know why it's still expecting a parameter when one should be being passed in.

    I also am very confused about calling methods in your middle tier (using the ObjectDataSource) and sending them back via a Dataset. When I was using vs.net 2003, I could simply drag a dataset object onto the form designer and refernce a strongly typed dataset in a middle tier project that the presentation tier was referencing. That way, the middle tier methods populate the dataset, pass it back up, then bind it to a datagrid, for instance. The same goes for populating the dataset in the presentation page and sending it down to the middle tier to update the database.

    A couple of things:
    I would like to know how to do this similiar functionality. There is no Dataset object in the toolbox to drag onto the form. When I try to add the strongly typed dataset of the referenced middle tier object into the app_code folder and compile, I get the following error msg:
    "'StronglyTypedDataSets.Settings' is inaccessible due to its protection level" - the assoicated generated code is as follows for this error:
    <code>

    private void InitConnection() {

    this.m_connection = new System.Data.SqlClient.SqlConnection();

    this.m_connection.ConnectionString = StronglyTypedDataSets.Settings.Default.NorthwindConnectionString;

    }
    </code>

    I can't seem to access the dataset, because its scope is Private.


    I also want to be able to use the Strongly Typed Datasets in my presentation tier which I have reference in my middle tier.


    The last thing is how come I don't have to write any code to get the data? When I load the page, it tries right away to load the data. I want manual control of when to call the methods in my middle tier to access and update the data.


    Can someone please help me in being able to successfully use the ObjectDataSoruce with strongly typed datasets? I know I'm missing something, but can't figure it out. I tried looking on the web and this forum, but can't find anything to solve the problem.

    Saturday, September 10, 2005 3:05 PM

All replies

  • User1520651007 posted

    After further testing, it appears that the ObjectDataSource doesn't work with strongly typed datasets. I'm getting the following error when I try to insert data:

    StronlyTyped dataset definition:
    <code>
    Private dst As New DataSet1 'this contains strongly typed columns
    </code>

    The Insert method using the strongly typed dataset:

    <code>
        <DataObjectMethod(DataObjectMethodType.Insert)> _
        Public Shared Sub InsertUnTypedCategory(ByVal dst As DataSet1)
            Dim ins As String = "INSERT INTO Categories " _
                & "(CategoryID, ShortName, LongName) " _
                & "VALUES(@CategoryID, @ShortName, @LongName)"
            Dim cmd As SqlCommand = _
                New SqlCommand(ins, New SqlConnection(GetConnectionString))
            cmd.Parameters.AddWithValue("CategoryID", dst.Categories.Rows(0).Item("CategoryID"))
            cmd.Parameters.AddWithValue("ShortName", dst.Categories.Rows(0).Item("ShortName"))
            cmd.Parameters.AddWithValue("LongName", dst.Categories.Rows(0).Item("LongName"))
            cmd.Connection.Open()
            cmd.ExecuteNonQuery()
        End Sub
    </code>

    "Message = "Could not find a property named 'CategoryID' on the type specified by the DataObjectTypeName property in ObjectDataSource 'ObjectDataSource1'."

    Even though the property is clearly defined within the hidden code-behind file for the TableAdapter within the dataset as follows:

    <code>
    <System.Diagnostics.DebuggerNonUserCodeAttribute()>  _
            Public Property CategoryID() As String
                Get
                    Return CType(Me(Me.tableCategories.CategoryIDColumn),String)
                End Get
                Set
                    Me(Me.tableCategories.CategoryIDColumn) = value
                End Set
            End Property
    </code>

    The ObjectDataSource only works with List collections as follows:

    <code>
    <DataObjectMethod(DataObjectMethodType.Insert)> _
        Public Shared Sub InsertListCategory(ByVal Category As Category) 'where Category is a Public class full of the column properties
            Dim ins As String = "INSERT INTO Categories " _
                & "(CategoryID, ShortName, LongName) " _
                & "VALUES(@CategoryID, @ShortName, @LongName)"
            Dim cmd As SqlCommand = _
                New SqlCommand(ins, New SqlConnection(GetConnectionString))
            cmd.Parameters.AddWithValue("CategoryID", Category.CategoryID)
            cmd.Parameters.AddWithValue("ShortName", Category.ShortName)
            cmd.Parameters.AddWithValue("LongName", Category.LongName)
            cmd.Connection.Open()
            cmd.ExecuteNonQuery()
        End Sub
    </code>

    This is too bad.... The strongly typed collection fills in all the properties for me when it's created at design time. What's the point of having the strongly typed collections when you can't even use them with the ObjectDataSource? Instead, you have to manually create a class that has all the column properties in it. It seems very redundant to me.

    Sunday, October 30, 2005 11:27 AM
  • User1520651007 posted

    After further testing, it also appears that the GridView control is impossible to use without some kind of DataSource control bound to it. This is evidenced by the following code in my presentation tier. I tried to pass the value down of the inserted items to my middle tier.

    <code>
    'Presentation tier
    Protected Sub DetailsView1_ItemInserting(ByVal sender As Object, ByVal e As System.Web.UI.WebControls.DetailsViewInsertEventArgs) Handles DetailsView1.ItemInserting

            Dim colVals As System.Collections.Specialized.IOrderedDictionary = e.Values
            Dim cls As New CategoryDB
            cnt = cls.InsertTyped(colVals)
            cls = Nothing

        End Sub
    </code>

    <code>
    'Middle tier
    Public Function InsertTyped(ByVal cols As System.Collections.Specialized.IOrderedDictionary) As Integer
            Dim ta As New DataSet1TableAdapters.CategoriesTableAdapter
            'Insert data
            Dim cnt As Int16 = ta.Insert(cols.Item(0), cols.Item(1), cols.Item(2))
            Return cnt
        End Function
    </code>

    The insert actually works, but upon return to the presentation tier, the ItemInserted event of the Gridview fires as follows:
    <code>
    Protected Sub DetailsView1_ItemInserted(ByVal sender As Object, _
                ByVal e As System.Web.UI.WebControls.DetailsViewInsertedEventArgs) _
                Handles DetailsView1.ItemInserted
            If e.Exception IsNot Nothing Then
                lblError.Text = "Invalid data. Please correct and try again."
                e.ExceptionHandled = True
            End If
        End Sub
    </code>

    An exception is thrown as follows when I don't have an InsertMethod specified:
    "System.NotSupportedException = {"Inserting is not supported by ObjectDataSource 'ObjectDataSource1' unless the InsertMethod is specified."}"

    An exception is thrown as follows when I have an InsertMethod specified:
    "ObjectDataSource 'ObjectDataSource1' could not find a non-generic method 'InsertTyped' that has parameters: CategoryID, ShortName, LongName."}"

    Even when I comment out the DetailsView1.ItemInserted, it still fires. In addition, when I disassociate the Datasource control from the GridView control, I still get an error message as stated above.

    Therefore, unless I'm wrong (and someone please correct me if I am wrong), don't plan on using the GridView control unless you plan to use it in conjunction with a DataSource control.

    Sunday, October 30, 2005 12:23 PM
  • User-109060882 posted
    Hi Bill,
    I recommend taking a look at the ASP.net QuickStart tutorials for ObjectDataSource:
    http://beta.asp.net/QUICKSTART/aspnet/doc/ctrlref/data/objectdatasource.aspx

    When you're using DataSets generated by Visual Studio, you can't use the DataObjectTypeName feature of ObjectDataSource. Using DataObjectTypeName makes some assumptions that just aren't true when it comes to DataSets - it's intended more for the custom object scenario.

    Thanks,
    Eilon
    Monday, October 31, 2005 7:35 PM
  • User1520651007 posted
    Eilon, in relation to the article you pointed out, there is a statement as follows:

    "The Update, Insert, and Delete methods should take individual data item fields as parameters, or they can optionally take an aggregate class object with public properties for data item fields."

    This article should be updated to specifically state that those methods cannot be used with Strongly Typed Datasets when using the DataObjectTypeName feature. It would avoid a lot of confustion the development community is experiencing with the ObjectDataSource and strongly typed datasets.

    Instead, you must pass parameters down to the Insert, Update & Delete methods individually when using strongly typed datasets or you must use a List collection or something similiar if using the DataObjectTypeName feature..

    This is still too bad, because as I stated before, it's redundant to have a strongly typed collection and a List collection that contain the same properties. Somehow, the strongly typed dataset should be made to handle the DataObjectTypeName feature. One of the requiremenets when VisualStudio builds the typed dataset would be to simply include a default constructor in the class which the ObjectDataSource is expecting:
    <code>
    Public Sub New()

    End Sub
    </code>
    Tuesday, November 1, 2005 10:01 AM
  • User1520651007 posted

    Eilon, I'm still trying to get a handle on updating a datasource with the ObjectDataSource control and a strongly typed dataset.

    It appears from the docs stated in my previous post, that you can use these two objects as long as you pass data down in the Update, Insert & Delete methods as individual parameters for the column properties. However, I find this not to be the case.

    I have a strongly typed dataset inside my App_Code directory with all the updateable methods. When configuring the ObjectDataSource against the strongly typed dataset, it sets the following properties of the ObjectDataSource:

    TypeName: DataSet1TableAdapters.CategoriesTableAdapter 'this is the hidden code behind file when the typed dataset gets created
    DataObjectTypeName: blank 'this would be the name of an aggregate class if one was being used.
    DeleteMethod: Delete
    InsertMethod: Insert
    OldValuesParameterFormatString: original_{0}
    SelectMethod: GetData
    UpdateMethod: Update

    The Gridview has the following parameters set:
    DataKeyNames: CategoryID
    DataSource: ObjectDataSource1

    Ensuring that the Update parameters being passed are the following:
    ShortName, LongName, original_CategoryID, Original_ShortName, Original_LongName ' these are the parameters on the Update method

    I'm getting the following error when trying to update a row in the Gridview:
    "System.InvalidOperationException: ObjectDataSource 'ObjectDataSource1' could not find a non-generic method 'Update' that has parameters: ShortName, LongName, original_CategoryID, Original_ShortName, Original_LongName"

    How come the Update isn't working passing down just individual fields instead of an aggregate class (which we know will not work with a typed dataset - which I hope will be modified in the RTM release)?

    Wednesday, November 2, 2005 12:26 PM
  • User1520651007 posted

    fyi, when I look at the parameter collection for the Update on the typed dataset, it includes the CategoryID as well as the other parms metioned in my previous post.

    I've tried it both ways (with and without the CategoryID parm), and it still doesn't work.

    I don't know why the error didn't originally bring up the CategoryID as part of the error message.

    It's still so frustrating to be able to get the ObjectDataSource to work with a typed dataset.

    I wish someone could explain some definitive properties that need to be set up where this supposedly works.

    Wednesday, November 2, 2005 12:36 PM
  • User1520651007 posted
    Eilon, I just want to make sure I understand this before I finish this issue...

    Through my testing, it's impossible to use strongly typed datasets with the INSERT, UPDATE or DELETE statements that are generated with these strongly typed datasets. The ObjectDataSource does not work with these datasets for the above methods.

    If that's the case, when using the ObjectDatasource, the INSERT, UPDATE & DELETE methods of the specific business object tableadapter (in the "configure DataSource wizard) should be ghosted out to avoid confusion. This leaves the assumption that these methods do work with typed datasets, which isn't true.

    In addition, if you make the mistake of using the ObjectDataSource to retrieve a strongly typed dataset, that works fine. The problem lies into the fact that as long as the ObjectDataSource is bound to a Gridview, and even though you set the INSERT, UPDATE & DELETE methods to nothing (and try to do the update manually (via the RowUpdating event), an error still occurs informing us that this will not work unless you specify the update methods for the ObjectDatasource, which we know is impossible with a typed dataset.

    Just wnat to amke sure....
    Thursday, November 3, 2005 12:01 PM
  • User1520651007 posted

    In other words, you should never use a Gridview control if you are planning to use it with a strongly typed dataset with the intention of using its update methods.

    If you are just using it to retrieve data, it works fine with a strongly typed dataset. That way, you can still take advantage of the sorting and paging capabilities within the ObjectDatasource that would be bound to the Gridview.

    If you plan to use the update methods of a typed dataset, you must use a DataGrid.

    Thursday, November 3, 2005 12:34 PM
  • User1974619475 posted

    Look here:

    http://forums.asp.net/1109106/ShowPost.aspx

     

    Thursday, February 23, 2006 10:58 AM
  • User-1614457691 posted

    Hi Bill,
    I recommend taking a look at the ASP.net QuickStart tutorials for ObjectDataSource:
    http://beta.asp.net/QUICKSTART/aspnet/doc/ctrlref/data/objectdatasource.aspx

    When you're using DataSets generated by Visual Studio, you can't use the DataObjectTypeName feature of ObjectDataSource. Using DataObjectTypeName makes some assumptions that just aren't true when it comes to DataSets - it's intended more for the custom object scenario.

    Thanks,
    Eilon

    Hmmm... that's odd because when I do not set a TypeName I get a RTE that says I must set a type name.

    Below is the error...

     

    Server Error in '/Abc.Xyz.Pll.Web' Application.
    --------------------------------------------------------------------------------

    A type must be specified in the TypeName property of ObjectDataSource 'ObjectDataSource1'.
    Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

    Exception Details: System.InvalidOperationException: A type must be specified in the TypeName property of ObjectDataSource 'ObjectDataSource1'.

    Source Error:

    An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. 

    Stack Trace:


    [InvalidOperationException: A type must be specified in the TypeName property of ObjectDataSource 'ObjectDataSource1'.]
       System.Web.UI.WebControls.ObjectDataSourceView.GetType(String typeName) +1261535
       System.Web.UI.WebControls.ObjectDataSourceView.ExecuteSelect(DataSourceSelectArguments arguments) +1936
       System.Web.UI.DataSourceView.Select(DataSourceSelectArguments arguments, DataSourceViewSelectCallback callback) +17
       System.Web.UI.WebControls.DataBoundControl.PerformSelect() +149
       System.Web.UI.WebControls.BaseDataBoundControl.DataBind() +70
       System.Web.UI.WebControls.DetailsView.DataBind() +4
       System.Web.UI.WebControls.BaseDataBoundControl.EnsureDataBound() +82
       System.Web.UI.WebControls.DetailsView.EnsureDataBound() +181
       System.Web.UI.WebControls.CompositeDataBoundControl.CreateChildControls() +69
       System.Web.UI.Control.EnsureChildControls() +87
       System.Web.UI.Control.PreRenderRecursiveInternal() +41
       System.Web.UI.Control.PreRenderRecursiveInternal() +161
       System.Web.UI.Control.PreRenderRecursiveInternal() +161
       System.Web.UI.Control.PreRenderRecursiveInternal() +161
       System.Web.UI.Control.PreRenderRecursiveInternal() +161
       System.Web.UI.Control.PreRenderRecursiveInternal() +161
       System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +1360


    --------------------------------------------------------------------------------
    Version Information: Microsoft .NET Framework Version:2.0.50727.42; ASP.NET Version:2.0.50727.210

    This is still a mystery, IMHO.

    Thank you.

    -- Mark Kamoski

    Monday, January 15, 2007 3:10 PM
  • User1082027797 posted
    That's because the TypeName and the DataObjectTypeName are two different things. The TypeName specifies the object that calls the CRUD Methods, while the DataObjectTypeName specifies the object that represents a single record which carries the data of the current record. Instead of passing a DataObject, you can use parameterized CRUD methods. In the latter case, the DataObjectTypeName must not be set.
    Tuesday, January 16, 2007 4:08 AM
  • User1553611380 posted

    One method would be to use the DataObjectMethodAttribute attributes and Partial Classes

     

        Namespace DataSetNameTableAdapters 'Change DataSetName to the name of your dataset 
            Partial Class TableNameTableAdapter ' Change TableName to the name of your table 
        
                 <System.ComponentModel.DataObjectMethodAttribute _
                 (System.ComponentModel.DataObjectMethodType.Select, True)> _
                 Public Function MyFunctionName(MyVariables) As DataSet.TableNameDataTable 'Change TableName with the name of your table 
                   Return Me.GetData()    
        
                 End Function
            End Class
        End Namespace
     
    Besure to check you have the right database operation (select, insert, update, delete) in the attribute. 
    Now you will be able to use the wizard in design mode to select your methods and set up your parameters. 
    Next you need to go to designer mode and select your objectdatasource and then open the properties windows. 
    Then you will need to change the property OldValuesParameterFormatString from original_{0} to {0}
    And now your function in the partial class will work properly. 
    I believe the reason it fails in the first place is because of this oldvaluesparameterformatstring telling the objectdatasource to append an original_ to the front of the first field. 
    When the objectdatasource appends the original_ then the parameter names are not the same, causing an error. 
     
     
    Tuesday, July 10, 2007 12:36 AM
  • User-683926522 posted

     I took your advice: deleted DataObjectTypeName from the ObjectDataSource and it works like a charm. It's unfortunate that the GUI puts it there, but it's a small price to pay for the time saved. Thanks! 

    Wednesday, May 28, 2008 5:12 PM
  • User-1614457691 posted

    All -- 

    IMHO and FWIW, Linq-To-Sql replaces Typed DataSets quite nicely.

    HTH.

    Thank you.

    -- Mark Kamoski

    Friday, June 6, 2008 8:40 AM
  • User715253857 posted

     Maybe Mr. Mitchell will do new tutorials with Linq.

    Wednesday, June 25, 2008 2:42 PM
  • User-1614457691 posted

     Maybe Mr. Mitchell will do new tutorials with Linq.



    There exists a great Linq tutorials written by Scott Guthrie.

    One can find the links here...

    http://wiki.asp.net/page.aspx/52/linq/

    HTH.

    Thank you.

    -- Mark Kamoski
    Thursday, June 26, 2008 10:13 AM
  • User715253857 posted

     They were ok, but they were not of the caliber of the data tutorials.  I remember trying to follow the Linq on Mr. Guthrie's page and found things missing.  I don't know that he meant it as the type of tutorial as appears on here.

    Saturday, June 28, 2008 10:23 PM
  • User2135110853 posted

    Am I understanding this correctly? Are you basically saying that the tutorials offered here for how to build a Business Logic Layer (BLL) are essentially WRONG, and THAT'S why I've lost two weeks of development time!?! All this time, I thought there must be some subtle syntactical difference with how it's done if you are using MySQL instead of SQL Server (besides that parameters use '?' instead of '@'). Well, then how ARE you supposed to build a working BLL that would be used from an ObjectDataSource, or is the lesson here to not use ObjectDataSource? (and that can't be it either since the BLL itself is generating errors, even though I followed the tutorial to a T.)

     Does anyone know how to make a working BLL (specifically Update and Insert) using MySQL 5.1 in Visual Studio 2005?

    Tuesday, January 27, 2009 6:24 PM
  • User-1338429632 posted

    All -- 

    IMHO and FWIW, Linq-To-Sql replaces Typed DataSets quite nicely.

    HTH.

    Thank you.

    -- Mark Kamoski

     Mark and Others,

    I'm new to these forums. I was just reading this post and wanted to ask you a couple questions. I am designing a web application, and have been trying to decide what kind of Data Model I would like to use (relational data, xml, strongly typed datasets, etc.). Each one seems to have its pros and cons. Most recently, I have been interested in the strongly typed datasets, because I can synchronize the XML. However, I can't seem to get a ObjectDataSource to work as the datasource so I can look at the data in design view. I can work with my strongly typed dataset just fine, even binding it to GridView controls or working with it programmatically in code-behind.

    You mentioned that "Linq-To-Sql replaces typed datasets quite nicely". Will it provide the capabilities I need to:

    • Work from XML data for portability across different platforms and applications (i.e.: Flash, win apps, web apps, web services, etc.)
    • Work with a subset of the xml, make changes, without affecting the rest of the XML "database"
    • Work with the data on-screen using in Design view, and easily bind data to Gridview controls, treeview controls, and other asp.net controls.

    What do you think?

     - Josh G

    Tuesday, February 10, 2009 2:24 PM
  • User-1614457691 posted

    Josh --

    Here are some thoughts for consideration, mostly my opinion, but it is what I do and it works. 

    You mentioned that "Linq-To-Sql replaces typed datasets quite nicely". Will it provide the capabilities I need to:

    >>>First, I will update my remarks to recommed Linq-To-Entites (rather than Linq-To-Sql), because Linq-To-Entites seems to be what MS is recommending as the preferred data acess future. As such, the rest of my comments here relate to Linq-To-Entites.

    [Will Linq-To-Entites] Work from XML data for portability across different platforms and applications (i.e.: Flash, win apps, web apps, web services, etc.)

    >>>It can, but it takes some work. It sounds like you are talking about serializing and deserialing, remotely distributed tiers, etc. As such, one would need a DTO (Data Transfer Object), IMHO, and as such one would need to build that layer. It is doable, but it is not native to Linq-To-Entites so it would need to be coded by hand (as far as I know) but someone has probably done it already.

    [Will Linq-To-Entites] Work with a subset of the xml, make changes, without affecting the rest of the XML "database"

    >>>The answer is more-or-less the same as noted above-- build a DTO layer.

    [Will Linq-To-Entites] Work with the data on-screen using in Design view, and easily bind data to Gridview controls, treeview controls, and other asp.net controls.

    >>>The answer is more-or-less the same as noted above-- build a DTO layer and, of course, make sure all DTO's are bindable.

    HTH.

    Thank you.

    -- Mark Kamoski

    Wednesday, February 11, 2009 11:45 AM
  • User-1338429632 posted

    Mark,

    Thanks for the reply. Actually, what I am trying to do is use an XML file (multiple xml files, actually) for all the data in my application. I am able to use XMLDatasource to populate Treeview controls, Menu controls, etc., by using XSL stylesheets to transform only the XML data I need. That much I have working.

    I also have built a custom strongly typed dataset based on an XML Schema I created. I used Microsoft's XSD.exe to create it. It works fine. Using the objects created by XSD.exe along with XMLDataDocument synchronization, I am able to access my XML data from code quite easily.

    The problem I have right now is, I want to be able to create somekind of Bindable object that I can use to not only get the data, but update it and add to it. I would think that would already be built-in to what XSD.exe generates. Maybe it is, and I just can't find it. I'm not sure. Any suggestions on how to go about this?

    Meanwhile, I'm going to read up on LINQ to Entities.

    Thanks again,

    Josh

    Wednesday, February 11, 2009 12:20 PM
  • User-1614457691 posted

    Regarding this... 

    >>>I want to be able to create somekind of Bindable object that I can use to not only get the data, but update it and add to it... Any suggestions on how to go about this?

    ...one can create a wrapper around a typed DataSet. That wrapper is decorated with an Attribute as a DataObject. That wrapper can then implement custom CRUD operations. As such, one will all the good things in a Typed DataSet and at the same time one will have all the good things in a custom object.

    This set of of tutorials explains how to do it from the ground-up...

    http://www.asp.net/learn/data-access/?lang=cs

    ...and it is a very good tutorial and a very good application foundation, IMHO...

    ...however, since you have a very custom architecture (custom XML data, custom XSDs, etc) you are going to have extrapolate from that tutorial just what you need...

    ...the whole tutorial is worth reading, IMHO, but to cut to it you in particular should see the section called "Creating a Business Logic Layer" where the objects are decorated with [System.ComponentModel.DataObject], all found at this link...

     http://www.asp.net/learn/data-access/tutorial-02-cs.aspx

     ...so that is where I would start.

    I have used that TypedDataSet tutorial as the basis for an application in the past and building it was easy, fast, etc-- so, I know it works.

    Note that the use of of the TypedDataSet is very controversial. For example, many respectable developers recommend that one should always avoid the TypedDataSet. Note that I am proponent of the TypedDataSet, as stated above-- but that is just MHO.

    HTH.

    Thank you.

    -- Mark Kamoski

    Wednesday, February 18, 2009 11:20 AM