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.
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".
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
I have problem inserting datetime values into my SQL Server 2008 R2.
The server is capable of handling ISO 8601 format, but If I send them as parameters, the SQL Server/OLE DB provicer, seems to be less tolerant on the timestamp string format.
I use OLE DB from C++ and would like to make my insert statement parametrized
INSERT INTO BATCH VALUES (?, ?, ?, ?....
When I specify timestamp values on the ISO8600 format, "2010-10-23T19:41:56.002+02:00", I get errors.
When enter the same timestamp format directly in the statement, I don't get errors
INSERT INTO BATCH VALUES ('2010-10-23T19:41:56.002+02:00', ?, ?, ?....
I have tried two different OLE DB providers. "Microsoft SQL Server Native Client 10.0" and "Microsoft OLE DB Provider for SQL Server"
They both behave slightly differently.
When sending the timestamp values as part of the SQL INSET, both providers accepts the following formats
2010-10-21 13:44:59.092 Is accepted by both
2010-10-21T13:44:57.092 Is rejected by Microsoft SQL Server Native Client 10.0 and accepted by the other
2010-10-23 19:41:56.002+02:00 Rejected by both providers
2010-10-23T19:41:55.003+02:00 Rejected by both providers
The both providers also report different errors
Microsoft OLE DB Provider for SQL Server reports "Conversion failed when converting date and/or time from character string" which I may understand.
The "Microsoft SQL Server Native Client 10.0" reports HRESULT=DB_S_ERRORSOCCURRED.
I would be glad if someone could explain these differences, especially why I can send the timestamp stirng litterally in the sql but not as a parameter.
I am using Visual Studio 2010 Professional.
I have created a new SQL Server 2008 Database Project, locally applied and deployed a simple scheme and stored procedure. Everything looks as it should until I try to create the unit test by right clicking the stored procedure, is this functionality only supported in Premium and Ultimate?