layer.dataSource Capitalization

[RichardHughes3]

Hello,

I am developing python addins that access a replica 10.2.1 file geodatabase.  When I list my layers and the access layer.datasource, I put these data sources into a python set object so that I will have one source path for multiple layers. 

There is a problem I am having with the capitalization of the dataSource in one of the layers.

See below:

['Database Connections\\Siskiyou.sde\\SISKIYOU.SDE.sdm_CrescentLink\\SISKIYOU.SDE.sdm_CablePathAccess', 'Database Connections\\Siskiyou.sde\\SISKIYOU.SDE.sdm_CrescentLink\\Siskiyou.SDE.sdm_CablePathAccess']

notice how one is in all caps and the other is not?  If there is a behavior layer dataSources that results in this behavior I am unaware of it.  Any advice would be greatly appreciated.

[VinceAngelo]

Table names are case-insensitive.  All comparisons should be done with an insensitive
operator or by first upcasing both strings.

Best practice is to reserve the SDE user for geodatabase administration.  Instead of
creating spatial data as SDE you really ought to create user(s) (with same-named
schemas) to own spatial tables, and user(s) to access it (without the possibility of
removing the tables accidentally, or as a result of a DOS attack).

- V

[RichardHughes3]

I have noticed depending on how and where layers are created in SDE the software changes the capitalization regardless of what I entered as the creation or output name.  What problem is it causing you?  If trying to set a layer by the source name then I would suggest to uppercase all layer name variables when looking for them, so they will match.  Would that help with this situation?

Thanks,
Sol

Using .upper() at the end of the dataSource fixed the problem and my python set() condensed the layer's dataSources down to a
single source.  This is just something I has to be included in all scripts with dataSources.  Thank you for your input.

[RichardHughes3]

Table names are case-insensitive.  All comparisons should be done with an insensitive
operator or by first upcasing both strings.

Best practice is to reserve the SDE user for geodatabase administration.  Instead of
creating spatial data as SDE you really ought to create user(s) (with same-named
schemas) to own spatial tables, and user(s) to access it (without the possibility of
removing the tables accidentally, or as a result of a DOS attack).

- V

Setting all upper case did solve the issue.  It will just remain a mystery.  I will have to do some additional research into your second
paragraph.  We operate by using versions, but alas I am not at that stearing wheel.

[VinceAngelo]

ArcGIS seems to be quirky on naming, depending on whether a user or an automated process
generated the table names.  Another variable is how the table was created, and how it was
registered with ArcSDE and/or the geodatabase.  The underlying databases which actually
support miXeD-cASe objects don't generally permit objects with alternate case representation,
so they're doing case-insensitive comparisons as well (sometimes, at least).  ArcGIS stores
the mixed-case name specified by the user in XML, but then the underlying ArcSDE executive
code might change case so it can find it later when the table is queried.

- V

[RichardHughes3]

Table names are case-insensitive.  All comparisons should be done with an insensitive
operator or by first upcasing both strings.

Best practice is to reserve the SDE user for geodatabase administration.  Instead of
creating spatial data as SDE you really ought to create user(s) (with same-named
schemas) to own spatial tables, and user(s) to access it (without the possibility of
removing the tables accidentally, or as a result of a DOS attack).

- V

Vince,

I created a new version under my user and connected to it using database connections.  Is that more or less what you were referring to?  The owner of my editing version is now richard instead of sde.

Thanks,

Richard

[VinceAngelo]

No, version name is completely orthogonal to table ownership. 

Sol and I recommended that you create at least one new user, not associated with any
individual login, to own the spatial data.  For example, I have a QA database with,
USA, EUROPE, and WORLD owners, who own the Usa.Highways_2m, Europe.Highways_2m,
and World.Highways_15m feature classes.  Others use departments or data sources as
owners (usgs.highways, census.blockgroups,...), or at a minimum a single owner
(projecta.table1).  This reduces the opportunity of accidently destroying the entire
geodatabase with a single unfortunate script or SQL command, isolates data from
individuals ("Who's Bob?" "Oh, he left years ago, but he created our geodatabase...")
and gives you the opportunity to follow the rest of best practices by creating roles
for table management, and granting access to users through roles.

- V

[RichardHughes3]

My current task is developing a python addin toolbar to help with my data production.  It works great most
of the time, but there are closed state issues that I need to seriously address at some point.  Anyway, I've read into the 'headless' user technique for restricting what operations can be performed on the database during scripting.  I've been absorbing the previous replies and seem to understand them as a need for user tiers with groups and permissions.  Is this an accurate assessment?