topic Re: Invalid index for field: [fieldname] in Layer: [layername] in ArcGIS Runtime SDK for iOS Questions

Invalid index for field: [fieldname] in Layer: [layername]

KristofferStenersen — Tue, 30 Jun 2015 07:26:39 GMT

Hi!

We´re using AGSGDB for offline features in our app.

We´ve added a field on our server side database. On such an event, the app detects a change in schema, does a full sync-recreate offline database cycle in order to be able to present this new field in the offline database. This has been working good for us, but now one of the clients are struggling syncing back features to the feature layer with the new field ("MaltAntPl").

The following server log message seem to correlate with this particular client:

SEVERE

Invalid index for field: MaltAntPl in Layer: Planting.

System/SyncTools.GPServer

Not sure if related, but we are also tracking the users "last login date", and here we see that the device probably has a bad Date&Time and Locale setting.

Any ideas what may cause this?

-Any tips on how we can get new fields in the offline GDB without a full re-create?:)

Cheers,

Kristoffer

Re: Invalid index for field: [fieldname] in Layer: [layername]

JuhoVainio — Fri, 10 Jun 2016 09:53:25 GMT

In case you haven't found out a solution, this might help you:

Check the offline GDB file's GDB_Items table and the Definition column. There you can see an xml data which contains an element LayerID. That ID must match the ID on the ArcGIS server or the sync will fail to "invalid index" error.

In my opinion the error message should be clear as to what actually is happening on the server side.

Re: Invalid index for field: [fieldname] in Layer: [layername]

DiveshGoyal — Fri, 08 Jul 2016 17:06:57 GMT

Is `MaltAntPl` a datetime field?

When you say "device probably has a bad Date&Time and Locale setting", how is it bad? Whatever be the locale of the device, the datetime is stored in UTC in the geodatabase.

We don't support altering the schema of the geodatabase on the fly. Replicas created from a feature service are tied to the db schema they were created with, and the definition of what data to include in the replica. You cannot later change the schema and expect existing replicas to continue working. Nor can you redefine an existing replica to update its schema or expand the scope of its data (for ex, the geographic extent, or layers, etc).

Re: Invalid index for field: [fieldname] in Layer: [layername]

JuhoVainio — Mon, 11 Jul 2016 06:27:46 GMT

I don't see any reason why you shouldn't be able to sync back a replica even when the online database schema has changed (for example adding more fields to a table). If the new fields are nullable or have a default value, then there should be no problem to sync the data back. The problem currently comes from the fact that you iterate the attributes on the server side and not from the replica when syncing the changes.

Also modifying the Layer ID numbers shouln't break the sync because you cannot add two layers/tables with the same name to the service. Therefore the name of the layer/table should be the identifier and not the Layer ID (which will change eventually).