Dataadapter Update command on tables with rowguidcol property for

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I'm accessing a SQLServer database wich is in a replication schema, the
tables has the rowguidcol attribute. The problem comes when I use the
Dataadapter.Update method it raises the next error "Updating columns with the
rowguidcol property is not allowed". I look around what the problem is, and
found the Update Command the VisualStudio 2003 makes automatically when
dragging the table to create the datadapter, it includes the rowguidcol
column into the updatecommand, so it brings out the error.

So, my question is: Is there any way to change (as automated as possible)
when I drop the table over the VS the datadapter update command generated,
ignores the rowguid columns? actually I have to change manually the command
to ignore that column.

Thanks everyone.
 
I've been disappointed with the CommandBuilder (used behind the scenes by
the DataAdapterConfiguration Wizard). It's not very smart or flexible when
it comes to building the Commands needed to provide updatability. While
there are some third-party tools that replace the DACW, there are no options
in the current version that will help in your case. In Whidbey, the DACW is
hidden and basically unchanged, but the TableAdapter Wizard (that replaces
it), has a bit more flexibility. It's supposed to support "RowId"
(Timestamp) concurrency, but I don't see anything that supports a GUIDs as
the PK.
Yes, many developers find that the drag-and-drop tools in VS are designed
for fairly simplistic designs.Yes, you can write your own wizards and
getnerate the sae action commands on your own. I've also heard of
refactoring tools that might be able to do this...

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
www.sqlreportingservices.net
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Bill, thank you very much. I found it out like you and many others
disappointing, I just can't believe they didn't consider the Rowguid
attribute if it is supossed to be used hand-by-hand with SQL Server. Actually
I solved it dragging all the fields, but the rowguid column, so the
dataadapter never knows about this field, and the problem gone. Any way it
opens a vulnerability when any change is made and want to drag the adapter
again, I must always remember to don't drag the entire table.

Thanks again, ragards
 
I know for a fact that the MS developers knew about the GUID and other
issues with the CommandBuilder. However, given the constraints of their
schedule and their options, they chose to implement something that fits a
simpler case--but does not work if things get more complex. I think it might
make sense to warn developers when the CB gets confused or recognizes one of
these problem cases, but doing so simply makes the ADO.NET DLLs heavier,
more complex and more trouble-prone (IMHO).

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com/blog/billva
www.betav.com
www.sqlreportingservices.net
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
 
Back
Top