arcpy.SearchCursor - features orders mixed up in Oracle enterprise geodabase

[MaximeDemers]

Something very weird happen when I use a SearchCursor over a feature class in an Oracle Enterprise Geodatabase

The order of the features in the SeachCursors changes depending of the field_names parameter that is used.

For instance:

source = "\\\\cnatrtd8\\geo\\ArcGIS Server\\Connections\\GEODEV011.sde\\GEO09E01_CS_FRA_GEN"
with arcpy.da.SearchCursor(source, ["OBJECTID"]) as cursor:
    ids = [row[0] for row in cursor]
    print(ids)

with arcpy.da.SearchCursor(source, ["OBJECTID", "CD_CS_FRA"]) as cursor:
    ids = [row[0] for row in cursor]
    print(ids)

>>>
[1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60]
[39, 40, 41, 42, 43, 44, 45, 46, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 47, 48, 49, 50, 51, 52, 53, 55, 56, 54, 57, 58, 59, 60]
>>>‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

This happen with many different features class, but only in the Enterprise Geodabase. The same features class in a File geodatabase dont do this.

What could be the cause of that?

[JoshuaBixby · Accepted solution]

In most database platforms, including Oracle, result set order is not guaranteed unless you use an ORDER BY clause.  If there is a need to guarantee an order in the cursor, you should specify the sql_clause parameter with an ORDER BY statement on the field you want ordered.

source = "\\\\cnatrtd8\\geo\\ArcGIS Server\\Connections\\GEODEV011.sde\\GEO09E01_CS_FRA_GEN"

with arcpy.da.SearchCursor(source, ["OBJECTID"], sql_clause=(None,"ORDER BY OBJECTID")) as cursor:
    ids = [row[0] for row in cursor]
    print(ids)‍‍‍‍‍