Simple question from new sql server user ... [modified]
-
Is is my first time i touching SQL server. I'm using sql server 2008 express. I created simple table using Management studio - and i connected to the table from C# code using dataGridView. I have small simple question ... 1. How can i define a new SP that can take parameters from C# code and how can i call it from C# code ?? 2. I add some new raw from the dataGridView - and i don't know why they are not save in the database ( i try to call 'AcceptChanges' - but still this is not working ) . Thanks for the help.
modified on Monday, October 25, 2010 8:43 AM
-
Is is my first time i touching SQL server. I'm using sql server 2008 express. I created simple table using Management studio - and i connected to the table from C# code using dataGridView. I have small simple question ... 1. How can i define a new SP that can take parameters from C# code and how can i call it from C# code ?? 2. I add some new raw from the dataGridView - and i don't know why they are not save in the database ( i try to call 'AcceptChanges' - but still this is not working ) . Thanks for the help.
modified on Monday, October 25, 2010 8:43 AM
Yanshof wrote:
dataGridView
Yuck. If all you're doing is seeing that it can be done, then use a DataAdapter's Fill and Update methods to move data between the Grid and the database. But it only works for very simple data and you will soon find that that technique is not appropriate for real applications. For one thing, Grids are generally not a proper way to get user input -- can you imagine an eCommerce site where you placed orders by filling in columns in a grid? No, you should define a form for entering and editing data. You can use a Grid with a subset of the data to allow the user to locate the record he wishes to edit, but never edit within a Grid. For actual applications you will need a Data Access Layer. A layered application makes swapping parts in and out easier. For instance, at some future time you may want the client to access the database via a Web Service -- if your client is too-tightly bound to your database, that will be much more difficult. "A stitch in time saves nine." Learn to use proper data access techniques now, before you really need them. Here[^]'s an article I wrote on one of my data access techniques.
-
Yanshof wrote:
dataGridView
Yuck. If all you're doing is seeing that it can be done, then use a DataAdapter's Fill and Update methods to move data between the Grid and the database. But it only works for very simple data and you will soon find that that technique is not appropriate for real applications. For one thing, Grids are generally not a proper way to get user input -- can you imagine an eCommerce site where you placed orders by filling in columns in a grid? No, you should define a form for entering and editing data. You can use a Grid with a subset of the data to allow the user to locate the record he wishes to edit, but never edit within a Grid. For actual applications you will need a Data Access Layer. A layered application makes swapping parts in and out easier. For instance, at some future time you may want the client to access the database via a Web Service -- if your client is too-tightly bound to your database, that will be much more difficult. "A stitch in time saves nine." Learn to use proper data access techniques now, before you really need them. Here[^]'s an article I wrote on one of my data access techniques.
PIEBALDconsult wrote:
never edit within a Grid.
And I would say to that: Never say "never". Without disputing the general thrust of your post, there are occassions when it makes perfect sennse to edit directly wihtin a grid, particularly if the underlying dataset has only a small number of "simple" fields (strings of limited length, or enum types from which the user has to choose for example.) One can (and should) still separate out the data access code into its own class, or layer, but as far as the user is cnncerned the editing can take place right there in the grid. It all depends on the exact situation, of course, but solutions should fit the problem; one shouldn't force a problem to fit a pre-determined solution. Just my tuppenceworth.
-
PIEBALDconsult wrote:
never edit within a Grid.
And I would say to that: Never say "never". Without disputing the general thrust of your post, there are occassions when it makes perfect sennse to edit directly wihtin a grid, particularly if the underlying dataset has only a small number of "simple" fields (strings of limited length, or enum types from which the user has to choose for example.) One can (and should) still separate out the data access code into its own class, or layer, but as far as the user is cnncerned the editing can take place right there in the grid. It all depends on the exact situation, of course, but solutions should fit the problem; one shouldn't force a problem to fit a pre-determined solution. Just my tuppenceworth.
In a couple of places I have allowed editing with a Grid, but only out of laziness to allow a knowledgable administrator to configure certain things, never for an average user to muck around with.
-
PIEBALDconsult wrote:
never edit within a Grid.
And I would say to that: Never say "never". Without disputing the general thrust of your post, there are occassions when it makes perfect sennse to edit directly wihtin a grid, particularly if the underlying dataset has only a small number of "simple" fields (strings of limited length, or enum types from which the user has to choose for example.) One can (and should) still separate out the data access code into its own class, or layer, but as far as the user is cnncerned the editing can take place right there in the grid. It all depends on the exact situation, of course, but solutions should fit the problem; one shouldn't force a problem to fit a pre-determined solution. Just my tuppenceworth.
NeverHeardOfMe wrote:
And I would say to that: Never say "never"
I have 1 very rigid rule, if you need to edit more than 1 field you will NEVER get a grid approved - go back and do the job properly. If you have only 1 field to edit I want a 3 page justification for not popping a dialog.
Never underestimate the power of human stupidity RAH
-
NeverHeardOfMe wrote:
And I would say to that: Never say "never"
I have 1 very rigid rule, if you need to edit more than 1 field you will NEVER get a grid approved - go back and do the job properly. If you have only 1 field to edit I want a 3 page justification for not popping a dialog.
Never underestimate the power of human stupidity RAH
Why is there such an objection to (simple) editing within a grid? Suppose you have a CMS used by the client to set up his shop. On one page you allow him to define "sections" - eg, "Toys", "Clothes", "Tools".. whatever. So what would be so wrong in displaying a grid of said sections and allowing him to edit their names there and then, and even add a new section via the footer row? I don't want a dialog for that, and I don't want to load a new page just to do this simple task, nor load the entire "section page" listing its name, sub-sections and/or items within it just to do it either. The trouble with dialogs in web-apps is that they come at a price - either you need the overhead of fancy javascript to create a modal one that also updates the calling page when closed (and, in the case of adding a new section will maybe need to redirect elsewhere too), or you run the risk of pop-up blockers getting in the way, or it openeing in a new tab and the client wondering what's happened. I don't see the necessity to take a strict "never edit in a griod" attitude. I quite accept it should be used only in limited cases, but not "never".
-
Why is there such an objection to (simple) editing within a grid? Suppose you have a CMS used by the client to set up his shop. On one page you allow him to define "sections" - eg, "Toys", "Clothes", "Tools".. whatever. So what would be so wrong in displaying a grid of said sections and allowing him to edit their names there and then, and even add a new section via the footer row? I don't want a dialog for that, and I don't want to load a new page just to do this simple task, nor load the entire "section page" listing its name, sub-sections and/or items within it just to do it either. The trouble with dialogs in web-apps is that they come at a price - either you need the overhead of fancy javascript to create a modal one that also updates the calling page when closed (and, in the case of adding a new section will maybe need to redirect elsewhere too), or you run the risk of pop-up blockers getting in the way, or it openeing in a new tab and the client wondering what's happened. I don't see the necessity to take a strict "never edit in a griod" attitude. I quite accept it should be used only in limited cases, but not "never".
NeverHeardOfMe wrote:
The trouble with dialogs in web-apps
I was pretty sure the OP was about a datagridview, and yes web apps have a different set of rules. My primary problem is that most junior devs want to do everything in a grid, which is fine when there are VERY limited interactions required. As soon as the interaction goes past the trivial they find the limitations of DGV editing. I am finding with Silverlight I can treat the web much like a winforms app, pop a dialog whenever I need to let the user edit the data.
Never underestimate the power of human stupidity RAH
-
Why is there such an objection to (simple) editing within a grid? Suppose you have a CMS used by the client to set up his shop. On one page you allow him to define "sections" - eg, "Toys", "Clothes", "Tools".. whatever. So what would be so wrong in displaying a grid of said sections and allowing him to edit their names there and then, and even add a new section via the footer row? I don't want a dialog for that, and I don't want to load a new page just to do this simple task, nor load the entire "section page" listing its name, sub-sections and/or items within it just to do it either. The trouble with dialogs in web-apps is that they come at a price - either you need the overhead of fancy javascript to create a modal one that also updates the calling page when closed (and, in the case of adding a new section will maybe need to redirect elsewhere too), or you run the risk of pop-up blockers getting in the way, or it openeing in a new tab and the client wondering what's happened. I don't see the necessity to take a strict "never edit in a griod" attitude. I quite accept it should be used only in limited cases, but not "never".
NeverHeardOfMe wrote:
web-apps
Oh, that's your problem -- they're rubbish.