nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

IFeatureClass.Update

GhassanKarwchan

I am migrating .NET code from 9.3 to 10.1
The code is using
IFeatureClass.Update(queryfileter, true) where true is for recycling.

I know recycling should not be used when we do update, and actually it was permitted on 9.3 in spite of being undesirable, and it is totally prevented on 10.1

On 10.1 the code is not working, so I assumed it is because of the recycle, and I did change it to false.

And here my first question. If it is not permitted , then why you give it as an option in 10.1 when we open a cursor of update?

Is it possible to use it in 10.1 with recycle being true?

and my second question.
After I changed it to false, I was able to successfully update the features.
It worked for all kind of update.
But it is hanging on one place, where I am selecting more that 100,000 rows at once.

The IFeatureClass.Update is hanging, without doing anything.

I want to ask if any one has any idea on how to do what I am doing on 10.1

P.S, I am maintaining very bad written and messy code, and what I need is just to migrate it to 10.1 with the less modification possible.

Thanks

Trouver plus de publications taguées avec

Accepted answers

All comments

LeoDonahue

Hi Sonia,

Everyone should really have this topic under their belt. "How to use cursors in the geodatabase"

I"m not sure "better way" is the phrase I would use. The options are based on what type of data you are editing and whether you are in an edit session. You may want to call update, but if the features you are editing are complex, you get overruled.

When working with simple features and edit sessions in an Engine application, it's recommended that a search cursor be used to take advantage of batched updates in edit operations. Outside of edit sessions, an update cursor allows performance and error handling advantages. With complex features, on the other hand, update calls are overridden by the features' custom behavior, meaning that the feature's store method will be called even if an update cursor is used.

NeilClemmons_GISinc

No, a recycling cursor does not release the feature objects. It uses the same instance of a Feature object over and over. For this reason, you shouldn't use a recycling cursor if you intend to modify the features it contains.

soniadickerson1

Thanks.

If I set recycling to true, correct me if I'm mistaken, but each feature will be release as soon as it moves to the next row.

_SFRMPSelectionSet.Update(null, true, out pCursor);

Per my testing, setting the recycling value to true does not cause any errors on low record volume.

Wouldn't this be a good way to go?

NeilClemmons_GISinc

This post has been very helpful. I had the same error but not for the same reason.

I found two ways to successfully edit the attributes and would like to know which way is better.

This one uses Update:

   _SFRMPSelectionSet.Update(null, false, out pCursor);         
         if (pCursor == null) { return false; }
           pRow = pCursor.NextRow();
           while (pRow != null)
             {
                 foreach (var pair in dictFieldsValues)
                 {
                   fldIndex = _SFRMPFeatureLayer.FeatureClass.Fields.FindField(pair.Key);
                   objectValue = pair.Value;          
                   pRow.set_Value(fldIndex, objectValue);
                 }
              pCursor.UpdateRow(pRow);
              pRow = pCursor.NextRow();

This one uses Store:

 _SFRMPSelectionSet.Search(null, false, out pCursor);        
         if (pCursor == null) {return false; }
           pRow = pCursor.NextRow();
           while (pRow != null)
             {
                 foreach (var pair in dictFieldsValues)
                 {
                   fldIndex = _SFRMPFeatureLayer.FeatureClass.Fields.FindField(pair.Key);
                   objectValue = pair.Value;
                     pRow.set_Value(fldIndex, objectValue);
                 }
              pRow.Store();
              pRow = pCursor.NextRow();

Thank you so much.

In general, using the Update cursor is faster, especially if you're updating a large number of records. However, there is a certain amount of overhead that comes with using the Update cursor. If you're only going to be updating a handful of records (less than a hundred or so), then the Store method is probably going to be quicker. If you don't know how many records you're going to be updating or if you're writing a general function where the number can vary, then go with the Update cursor.

soniadickerson1

   _SFRMPSelectionSet.Update(null, false, out pCursor);         
         if (pCursor == null) { return false; }
           pRow = pCursor.NextRow();
           while (pRow != null)
             {
                 foreach (var pair in dictFieldsValues)
                 {
                   fldIndex = _SFRMPFeatureLayer.FeatureClass.Fields.FindField(pair.Key);
                   objectValue = pair.Value;          
                   pRow.set_Value(fldIndex, objectValue);
                 }
              pCursor.UpdateRow(pRow);
              pRow = pCursor.NextRow();

This one uses Store:

 _SFRMPSelectionSet.Search(null, false, out pCursor);        
         if (pCursor == null) {return false; }
           pRow = pCursor.NextRow();
           while (pRow != null)
             {
                 foreach (var pair in dictFieldsValues)
                 {
                   fldIndex = _SFRMPFeatureLayer.FeatureClass.Fields.FindField(pair.Key);
                   objectValue = pair.Value;
                     pRow.set_Value(fldIndex, objectValue);
                 }
              pRow.Store();
              pRow = pCursor.NextRow();

Thank you so much.

AlexanderGray

Leo is making valid points and was right to ask what is the error message. The other half of the equation is, of course, what code is generating this message. However, if one assumes there is only one way to edit, one might not think to provide that information. With a little more info to start with there is a lot less confusion.

LeoDonahue

ok

I am not sure what we are arguing or discussing about.

I know it is illegal.
My question was, why ESRI provides (recyclable option) on update cursor if it is not going to work.
That was my question

Forget about this thread, and thank you for creating all that noise with no answer.

I will create another post

I didn't know we were arguing.

ESRI provides an API that has a boolean parameter to a method. Let's talk about how you use it. If you are not using an edit session, nor calling the store method, but you set the parameter to use recycling, and your record that you are updating is using the updateFeature method on a single feature, would that not update the feature attribute?

Noise is the result of not sharing the error message with us in your first post. Posting questions that say something hangs and doesn't do anything, then indicating you get errors in a second message, and leaving out that information only allows us to guess at your problems. If I hadn't asked, I don't think you would have posted the error message.

GhassanKarwchan

Ghassan,

There are many ways to do updates. Are you using store on the feature or are you calling updatefeature on the featurecursor? Are you inside an edit session (on the editor extension or on IWorkspaceEdit) or not in an edit session? If in an edit session are you in an edit operation? Are you using com release on each feature after the edit is done? Have you place the featureclasses in load only mode? Is the data in a enterprise database or a file database? If in a enterprise database, is the data versioned? You may be running out of memory if you don't release any of the features as you go along. You could be filling up user allocated space on the database also.

Thanks agray
Finally someone that is making sense in his answer.
I will look at this options in more details.
maybe I am running out of memory.
The code is not mine, and I was just try to do fast migration to 10.1
but seems I have to read the code

GhassanKarwchan

That error matches exactly what the documentation says is illegal to maintain, that I quoted earlier.

ok

I am not sure what we are arguing or discussing about.

I know it is illegal.
My question was, why ESRI provides (recyclable option) on update cursor if it is not going to work.
That was my question

Forget about this thread, and thank you for creating all that noise with no answer.

I will create another post

LeoDonahue

FDO_E_CANNOT_STORE_RECYCLED_ROW_IN_EDIT_SESSION

http://help.arcgis.com/en/sdk/10.0/arcobjects_net/componenthelp/0025/0025000000mn000000.htm

[TABLE="class: dtTABLE"][TD="class: t"]FDO_E_CANNOT_STORE_RECYCLED_ROW_IN_EDIT_SESSION[/TD]
[TD="class: t, width: 25%, align: left"]-2147219112[/TD]
[TD="class: t, width: 32%, align: left"]Cannot call Store on a recycled row while editing.[/TD]

[/TABLE]

That error matches exactly what the documentation says is illegal to maintain, that I quoted earlier.

AlexanderGray

Ghassan,

There are many ways to do updates. Are you using store on the feature or are you calling updatefeature on the featurecursor? Are you inside an edit session (on the editor extension or on IWorkspaceEdit) or not in an edit session? If in an edit session are you in an edit operation? Are you using com release on each feature after the edit is done? Have you place the featureclasses in load only mode? Is the data in a enterprise database or a file database? If in a enterprise database, is the data versioned? You may be running out of memory if you don't release any of the features as you go along. You could be filling up user allocated space on the database also.

GhassanKarwchan

What kind of error message would I get?

FDO_E_CANNOT_STORE_RECYCLED_ROW_IN_EDIT_SESSION

LeoDonahue

What kind of error message would I get?

GhassanKarwchan

Where did you read that it is prevented in 10.1? The docs suggest that you do not modify features returned by a recycling cursor.

Idonahue. I assume you didn't write a code that is trying to update rows returned by a recyclable cursor in 10.1 yet. Because if you did, you will get an error message.

LeoDonahue

I know recycling should not be used when we do update, and actually it was permitted on 9.3 in spite of being undesirable, and it is totally prevented on 10.1

Where did you read that it is prevented in 10.1? The docs suggest that you do not modify features returned by a recycling cursor.

The recycling parameter controls row object allocation behavior. Recycling cursors rehydrate a single feature object on each fetch and can be used to optimize read-only access, for example, when drawing. It is illegal to maintain a reference on a feature object returned by a recycling cursor across multiple calls to NextFeature on the cursor. Features returned by a recycling cursor should not be modified. Non-recycling cursors return a separate feature object on each fetch. The features returned by a non-recycling cursor may be modified and stored with polymorphic behavior.

Why give it as an option? Because ESRI assumes you will use it wisely.

The false parameter means use a non-recycling cursor, which is safe for making updates. FeatureCursors aren't that fast when you are making updates, especially on 100,000 rows, and especially if you are in a programmatic edit session. Are you updating attributes or actually updating the geometry of the feature on those 100,000 rows?

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.