I ran into a small problem using the LinqDataSource as a datasource for a GridView or ListView (the new 3.5 ListView features quite nice functionality, with an insert-capable grid!).
I had set up a datasource with a ListView bound to it which had a button per row to call the ‘Delete’ command. The other commands seemed to work fine (insert, edit) but the delete command didn’t do anything. Just a postback; no exception, no deletion, nothing.
After a lot of debugging, I found out I had set the primary key of my Linq object to be ‘readonly’. I had done this to prevent users from altering the PK and thereby breaking the database. Since the primary key was a generated uniqueidentifier anyway, I didn’t want my users to mess with it.
Anyway; after removing this setting (thus setting it not to be read-only), it suddenly deleted records just as I wanted it to.
The designer’s description for the Read Only setting is: “Controls whether an a set accessor is generated.”. That’s because each column/members get’s its own property with a get/set accessor. I’m not quite sure why this disables the possibility of deleting an object. Perhaps because you can’t create the object without setting it’s primary key, which makes sence. But then again; how is the object populated from the database with the correct private key and why is that method not used to populate it again on postback? Better yet: I would suppose the entire object is stored somewhere in the viewstate between postbacks so the primary key should be in there somewhere, right?
I’m not quite sure about why, but I do know you’d better leave your primary key not be read-only, unless you never want to delete that object.