[RESOLVED] GridView DataSource Edit

[weirddemon]

I have a DataView that is bound to a DataSource, which gets its data from a SQL database.

I'm converting a desktop app to a web app and I've been able to duplicate the data query side, but I'm having a hard time inserting a new record via the data source. In the desktop app, I don't use a data source. I have a class I created that inserts a new record, but the upkeep is extremely time consuming, so I'm switching to the datasource.

When I assign the datasource, I selected the SQL statement/stored procedure option and created my INSERT command via the Query Builder.

The problem I'm running into is that I don't want a SELECT statement. I just want a plain GridView so I can select Edit, fill in the data and then call InsertParameters.

If I don't add a SELECT statement, it won't let me finish the wizard and an invalid one throws an exception. The only other thing I could think of, was to call SELECT and set a WHERE based on a column whose value is null. The app runs, but the GridView doesn't appear.

Does anyone know how I can only do an INSERT?

[weirddemon]

Does anyone have any ideas? This is so frustrating. I've been trying everything I can for several hours now. Pouring through page after web page isn't helping either.

Every example and info I'm finding has nothing to do with inserting a new row. It's all about updating an existing row. Which I'll need to do eventually, but right now, I need to just add a new row via a datasource. Surely that's possible.

[weirddemon]

Never mind. I just decided to make a basic form via labels and text boxes and use that to insert the new record.

[gep13]

Hello weirddemon,

If I were to give you one piece of advice, it would be to stop using the SqlDataSource. If you continue to use it, you are just going to find more and more things that annoy you about it. You will be in a much better position if you abstract the code in DAL and BLL and access the data using ADO.Net, and use business objects to bind to the UI.

Just my two cents worth...

Gary

[weirddemon]

Hello weirddemon,

If I were to give you one piece of advice, it would be to stop using the SqlDataSource. If you continue to use it, you are just going to find more and more things that annoy you about it. You will be in a much better position if you abstract the code in DAL and BLL and access the data using ADO.Net, and use business objects to bind to the UI.

Just my two cents worth...

Gary

The reason I'm using a SQLDataSource was to eliminate the upkeep of the methods used to extract data, update, etc. It makes it 100&% easier to allow the data source to do all of that for me. I was spending a ton of time just trying to get all that to work with the UI and the data source allows me to stop wasting so much time.

The methods you mentioned are completely unknown to me. So I can't tell if it would best for me to use. I'm going to look them up, but without a point of reference, I'm fumbling in the dark.

[gep13]

Hello,

I am sorry, but, personally, I have to completely disagree with you.

Although to start with you may think that the SqlDataSource is helping you (and I agree, it can appear that way) it really isn't. By using the SqlDataSource you are directly tying the User Interface (your ASPX pages) to the underlying database. Any chance to the database would require a complete change to the UI.

In terms of code segregation, logical layers, and testability, the use of the SqlDataSource is completely flawed, IMO.

If you are looking for more information about using ADO.Net directly to complete the access to the database then you can take a look at the links in my signature

Gary