Alter Field Failed in c#.

[zhouyang]

Hello, everyone.

Recently, I did a test to alter one of the fields let say "CITY_NAME" in "Shapes.gdb" based on the samples from download file "FileGDB_API_VS2010_1_3.zip".  But I always encountered a exception message "Attempted to read or write protected memory. This is often an indication that other memory is corrupt."

The below is the field def:

<esri:Field xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:esri='http://www.esri.com/schemas/ArcGIS/10.1' xsi:type='esri:Field'><Name>CITY_NAME</Name><Type>esriFieldTypeString</Type><IsNullable>true</IsNullable><Length>100</Length><Precision>0</Precision><Scale>0</Scale><AliasName>CITY_NAME</AliasName><ModelName>CITY_NAME</ModelName></esri:Field>

Also, I found the function worked fine in TableSchema sample. I compared both of them and the biggest difference is: the field def from mine is I created by myself and I didn't know the real field def when created "Shapes.gdb". The TableSchema sample which works fine is it created a new Geodatabase file from a xml file on the fly, then alter it successfully in this way.

I am not sure if there might be some missing nodes in my field def like Domain,RasterDef which caused the exception since i didn't know the original structure of the Geodatabase file. But, i just alter a normal field which shouldn't include those nodes.

I have attached the demo project to show this issue and I have deleted "Shapes.gdb" and FileDDB DLLS for uploading size limitation, both of them can be found in the "FileGDB_API_VS2010_1_3.zip" from Esri. Hope your guys can get me out of this trouble so that I can continue my project.
Environment:
OS: window 7 sp1 X64
VS 2010 framework 4.0

Thanks in advanced.

[zhouyang]

Is there any reply? or I didn't descript the question clearly?

[LanceShipman]

If I'm reading your code correctly, you are trying to change the length of a character field. This is not supported.

Currently the documentation doees not indicate what is and is not supported. I will enter a bug and correct this at the next release.

[zhouyang]

Ok, lshipman, Thanks.
But btw, does it means it also not support altering the field type, let say from interger to string? Or the altering field function is totally not works?

Anyway, It still saves me a lots of time to debug. Now, we have worked with a workaround for this. In case of others encounter the same issue, I list the steps:
1. create a new gdb file with the same structure from original file.
2. delete the field which would be altered from the new one.
3. Add a new field which is the modified field def in the new one.
4. Insert all the rows into the new gdb file from original gdb file.
5. delete the original file.
6. rename.
But we know it causes a bad performance.

We still expect that your team would accomplish it in the future so that we can changed our logic.
Thanks.

[VinceAngelo]

What possible business case is there for dynamically changing column width
*or* column type?  I've been writing spatial data translators for 25 years,
and I've never encountered the need.

Recreating the table is *less* likely to cause performance issues than
fracturing a table by changing the column definitions.

- V

[zhouyang]

Actually, one of our customers ask for us about this case.
A simple case is when user found the field defined before is not suitable then he want to alter it.

What we think is FileGeodatabase is a database which means we can manager it from creating to destroying. And what we do now is like a database management tool which support create/edit/delete a filegeodatabase, so do its tables.

Perhaps this case is not common in spatial data translators but I guess it should be common in database management tool.
And also, I am confuse since you think this case is less, but why you provide this Api and then let it do nothing?

[VinceAngelo]

I'm used to doing a database design before I start collecting data.  If I have the
types wrong, it's because I did a poor job on the database design, and I need to
go back to start in the design process.

File geodatabase, especially through the FGDB API, is just about as mature as
you'd expect it to be for its age.  Comparing it to 20 year old databases (most
of which still don't permit you to change type) isn't fair to either.

The FGDB API was released to allow read and write access to geodatabases
outside of ArcGIS.  It certainly wasn't meant to become the basis of the next
SQL-Developer app.  I wasn't part of the design or implementation of the API,
so I'm not sure why an Alter Field even exists (I'd only expect it to work for
changes to the formatting of fixed-width types).   If you're expecting a lot  of
new development on the API, to support functionality not related to spatial
data translators (fmtX-to-fgdb or fgdb-to-fmtX), then I'm sorry, but you're
probably going to be disappointed.

- V

[zhouyang]

Thanks for your explanation.
I think I have got what I want. 🙂