• 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.

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.

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.

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

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>

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)?

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.

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....

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.

Look here:

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

 

Eilon:

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

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.

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. 

 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! 

All -- 

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

HTH.

Thank you.

-- Mark Kamoski