Quirky row behavior when created by search loop

1612
3
05-01-2012 12:23 PM
MarkCederholm
Occasional Contributor III
I've noticed that row objects tend not to like to travel outside the scope of a search loop, even if the unique option is set.  For example, this code works OK:

   foreach (Row r in tab.Search("*", "", RowInstance.Unique))
   {
    this.Manipulate(r);
    tab.Update(r);
    break;
   }


Whereas this can crash with a protected memory violation:

   Row row = null;
   foreach (Row r in tab.Search("*", "", RowInstance.Unique))
   {
    row = r;
    break;
   }
   if (row != null)
   {
    this.Manipulate(row);
    tab.Update(row);
   }


This seems to go against common programming sense, but obviously code design can accommodate this.
0 Kudos
3 Replies
VinceAngelo
Esri Esteemed Contributor
That's more of a language issue than anything else.  I'd be afraid to access an iterated object
outside its valid scope.

- V
0 Kudos
MarkCederholm
Occasional Contributor III
Yeah, I guess I've gotten too used to working with COM objects, which have a life of their own.
0 Kudos
VinceAngelo
Esri Esteemed Contributor
It would be best to create a new Row for update, anyway, using two cursors, so the loop
would need to generate a new update row per processed feature, or cumulate the changes
in the loop, and implement them afterwards.

- V
0 Kudos