After I change the precision and scale for my short, long, float, and double field types when creating a table in ArcMap SDE geodatabase, ArcMap will reset my precision and scale to default values. For instance, I wanted my short integer to have a precision of 3 in one table and 2 in the other so I could test some python code. ArcMap changed them both to precision of 5 automatically and the python tool isn't given a proper test.

Please note that this is a different but related issue that was addressed here: Specifying precision and scale of new field using ArcPy? I know how to specify the precision, but ArcMap isn't keeping my settings.

If this makes sense stop reading here. If you want more detail, please continue reading:

I am creating an enterprise geodatabase in ArcMap 10.2.1 for the purpose of testing two tables: a source table and a destination table. I am building a tool that will describe the tables, put the field names as keys in a dictionary and the field objects as values, populate a list of all matching fields, then a series of if statements remove the fields that may have the same name, but incompatible data types, precisions, scales, and field lengths. Incompatible is different than non-matching. I created if statements that allow a short integer in a source table to be compatible with a long integer(or a float, or a double) in a destination table. But this cannot be reversed. Only a short can go into a short. But if they have different precisions, a smaller or equal precision can go into a larger precision, but a larger precision cannot go into a smaller one.

This is why I need ArcMap to keep my varying precision values across different fields. I need to be able to test every possibility.

#           Pass SmallInteger types if going into a SmallInteger.

            if source_type == 'SmallInteger' and destination_type == 'SmallInteger':

#           Filter out incompatible precision.
                if source_precision <= destination_precision:
                if source_precision > destination_precision:

That is my issue. If anyone can get my enterprise geodatabase to behave, please let me know!

I'm using ArcGIS 10.2.1.

closed as unclear what you're asking by PolyGeo Nov 17 '17 at 6:12

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • ArcMap just sees numbers. The default precision and scale in ArcMap have nothing to do with what's in the database. The database settings control how many decimal places are actually stored in the database but due to the way IEEE floating point works it will return more decimal places than are actually there. I think there is a way to change the default precision and scale in ArcMap but I can't remember it right now, I'll do some research and get back if I find something. – Michael Stimson Jul 2 '14 at 22:10
  • I am not sure if this is DBMS specific but I think it would be useful for you to edit your question to include the DBMS that you are accessing via ArcSDE. – PolyGeo Jul 2 '14 at 23:57
  • Ok, I'll look for it. Keep in mind that I was able to change the precision and scale for all the numeric fields, but the next time I opened ArcMap, it had changed all of them. Short Integers all got 5 precision even if I set them lower. – keepaustinbeard Jul 3 '14 at 17:20
  • My professor came up with a possible solution: try creating my SDE geodatabases in ArcCatalog instead of the window in ArcMap. She told me the window isn't as functional as the full ArcCatalog program. If I get it to work I'll update this issue and mark it as solved. – keepaustinbeard Sep 15 '14 at 3:44
  • Sounds like you maybe having this issue because of how tings work in ArcGIS. "By default in ArcGIS Desktop, short integers are created with a precision of 5". See desktop.arcgis.com/en/arcmap/latest/manage-data/geodatabases/… – ZZZ Sep 2 '18 at 21:29