Quirky row behavior when created by search loop

[MCederholm]

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.

[vangelo]

That's more of a language issue than anything else. I'd be afraid to access an iterated object
outside its valid scope.

- V

[MCederholm]

Yeah, I guess I've gotten too used to working with COM objects, which have a life of their own.

[vangelo]

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