How to update primary key through texbox and datagridview

Question

1.00/5 (2 votes)

See more:

I am using windows form with C#, I have a gridview and 4 texboxes and update button, I want to update the selected row through texboxes, I am able to change name, size, date but I can't change Id, I want to be able to change all the columns. How can I do that !!

C#

private void Updatebtn_Click_1(object sender, EventArgs e)
       {

               SqlConnection conn = new SqlConnection(@"Data Source=Ali-pc\sqlexpress;Initial Catalog=DB;Integrated Security=True");
               SqlCommand cmd = new SqlCommand("update stock set Id=@Id, Name= @Name,  Size= @Size, Date=@Date where Id=@Id ", conn);
               conn.Open();
               cmd.Parameters.AddWithValue("@Id", textBox1.Text);
               cmd.Parameters.AddWithValue("@Name", textBox2.Text);
               cmd.Parameters.AddWithValue("@Size", textBox3.Text);
               cmd.Parameters.AddWithValue("@Date", dateTimePicker1.Value);
               cmd.ExecuteNonQuery();
               MessageBox.Show("Successfully Changed ", "message", MessageBoxButtons.OK, MessageBoxIcon.Information);
               DataTable ds = new DataTable();
               SqlDataAdapter sda = new SqlDataAdapter("Select * from stock", conn);
               sda.Fill(ds);
               BindingSource bs = new BindingSource();
               bs.DataSource = ds;
               dataGridView1.DataSource = bs;

           }

Posted 21-Nov-15 8:47am

R.M49

Add a Solution

Comments

PIEBALDconsult 21-Nov-15 15:12pm

Do not EVER change an ID!

Sergey Alexandrovich Kryukov 21-Nov-15 18:22pm

This question may still make some sense, but the inquirer thinks along the wrong lines. It raises important problem which can be solved in different ways, and one of them is database modeling in the framework of relational model.
Please see Solution 1. Perhaps it's too far-going, but everything else base on relational database would not make sense.
—SA

Sergey Alexandrovich Kryukov 21-Nov-15 17:56pm

Why, indeed? Do you understand that this part of database is metadata (part of database schema), not ordinary data; it should not be modified by applications?
—SA

Patrice T 21-Nov-15 17:57pm

Never change a primary key, never.

Sergey Alexandrovich Kryukov 21-Nov-15 18:22pm

This question may still make some sense, but the inquirer thinks along the wrong lines. It raises important problem which can be solved in different ways, and one of them is database modeling in the framework of relational model.
Please see Solution 1. Perhaps it's too far-going, but everything else base on relational database would not make sense.
—SA

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Answer 1 · 2015-11-21T12:20:00

Please see the comments to the question, by PIEBALDconsult, ppolymorphe and mine. They should explain you why your question makes no sense at all. This key is a part of metadata, which is defined when you define tables, attributes and other components of database schema.

But I can show you a way of you need to develop a system where you can "change all columns". I understand where it can be good to do, but you are thinking in a totally wrong direction. I'll explain you, but you well need to exercises vivid imagination, to grasp it.

Here is what you can do: you can "change the columns", but not in the database you are working right now, but in the tables of another database, the one you model inside your database. Are you getting the idea? You have to use your database to create a schema which is intended to model some simpler database inside your database. In other word, you model some of the database concepts in your schema. You can model the concepts such as "property", "attribute", "key" and "table" inside your database. Then you can have tables of properties, tables, attributes, and so on. Let's say, you are doing it in your database you are working with right now. Let's call it "implementation database". It's schema will model another database inside it; call it "model database". The concepts of "property", "attribute", etc. will be the concepts of the database metadata for your model database. Then you will need to model its data written according to the metadata.

I'll explain it on a simple example. Let's say, you want to implement the table with some records, and the columns of this table can be added or renamed at any time. For simplicity, let's assume that all keys and all data elements are just strings. Here is what you can do. Define table of "column names" or "properties", and table of "values". Then define the table of "cell". Each cell would be a database record with two keys: one pointing to a "property" and one to "value". This way, values can be reused. And then your table in the model database will be composed as a table of "cells". This way, you can have a set of "property/value" pairs (key/value, if you will) which can be represented as a table (modeled table, not table of your implementation database) which can be understood as a table which columns are properties and cells are values. But in fact (in implementation presentation), this is just a relation between "properties" and "values". What happens when you change the "property name"? Nothing bad; the integrity of your implementation database will still preserved, that "column names" are not keys, just a set of names (strings). Same way, you can add a new "property" object. It can be represented as a "new column" not filled with any values. Values will be added when you set some keys pointing to existing values or new values.

Can you grasp the idea? If not, it's possible that the best thing for you would be learning the relational model; your question indicates that you don't quite understand it at the moment. Anyway, your follow-up questions will be welcome.

—SA