Globalizing Web Community Menu

Home
Mission
Message
Blog
Downloads
Favorite Links
Thanks
Invitation
Coty

     
Login or Register
Information Site

Back To Blog

Archive Links


August 18, 2006


February 25, 2006
February 8, 2006
January 15, 2006
November 16, 2005
October 31, 2005
October 1, 2005
September 20, 2005
September 3, 2005


   

6/22/2008

Using ObjectDataSource instead of SqlDataSource for the Web connection

As I could not utilize the SmartTag function to generate SqlDataSource for TIMEO, I attempted to generate ObjectDataSource with the SmartTag, which proved to be successful.


I could set up the data display pages for the Bots, Comments, Commentsja and Peron tables automatically using the Smart Tag. The Smart Tag function displays all the methods by the drop down list residing in the SqlManagement class and let me select the standard display method. This method takes the “table name” as the string parameter and displays all the rows of the specified table. However, I hit the stumbling block, when I tried to extend this function to “Delete”, which is supposed to call the standard delete method residing in the same class. This method takes the integer parameter for the ID of the row to be deleted, in addition to the table name. Here, the code generated by the Smart Tag could not find the delete method selected. I could not find the reason why.

Therefore, I resorted to the good old way of manually entering the ID number in a text box and calling the standard delete method by the push of a button. When testing this method with the Person control page, I experienced the SQL error at the following line:

int RowsAffected = MyCommand.ExecuteNonQuery();

Although the compiler showed the error message, I could not find the reason for the error from this message. Therefore, in order to find out the reason for this error, I had to read the SQL Exception message by revising the standard delete method as follows:

Try
{
MyConnection.Open();
int RowsAffected = MyCommand.ExecuteNonQuery();
MyConnection.Close();


return RowsAffected.ToString();
}


catch (SqlException SQLexc)
{
return SQLexc.ToString();
}

With this revision, I could find that the error was in the inline SQL command, where I inadvertently added * after delete, which was carried over from the select command. Furtheremore, I forgot to add @ in front of the parameter name. In future, I should always using this syntax so that any error could be quickly found by the SQL exception message.

Comments: 0    Trackbacks: 0




Write a comment

TrackBack Address:
http://www.timeo.com/TrackBack.aspx?ID=118
   

RSS FEED