Enterprise ArcSDE Object Limit???

[JerryGarcia]

What is the maximum number of tables/feature classes for an Enterprise GDB? Is there a similar reference for ArcSDE using SQL Server?  http://resources.arcgis.com/en/help/main/10.2/index.html#//018s00000002000000 This is from Microsoft: https://technet.microsoft.com/en-us/library/aa933149%28v=sql.80%29.aspx Thanks!

[MartinAmeskamp]

Hi, coming abit late into this discussion ...

Microsoft suggests implementing row-level security by using views: If you want to restrict access by, say, user, put a column USER on your tables and use a view with "where table.USER = CurrentUser()" to restrict access.

Question: Would this view be a first class citizen in ArcGIS? Adding data, publishing feature services, ...?

Thanks, Martin

[JerryGarcia]

Good question.  If you can do this, how would you do this with  Windows AD: *EGDB SQL Server -> ArcMap *EGDB SQL Server -> ArcGIS Server -> Web Clients Thanks!

[VinceAngelo]

There are so many things wrong with using user as a WHERE constraint that it's hard to take that suggestion seriously.  And no, a view cannot treated as table by ArcGIS.

- V

[JerryGarcia]

That's good info.  Can you provide any Esri on-line references to support this pretty clear conclusion?

[VinceAngelo]

There probably are documentation references to the limitations of views, but I've never bookmarked any.

[George_Thompson]

Here is some information for 10.3.x and views in a database/geodatabase (specifically in SQL Server):

Views in an enterprise geodatabase—Help | ArcGIS for Desktop

View database data in ArcGIS—Help | ArcGIS for Desktop

Hope this helps with any clarification.

-George

[MartinAmeskamp]

OK - clear words. I'd taken this suggestion from the Microsoft SQL Server docs on row level security, and yes, the username wouldn't be my first choice, so forget about that.

What about an ID (i.e. project ID, customer ID). Could one take that seriously? If not, why? Any alternatives? I recently heard about Server Object Interceptors that could provide some sort of masking to implement selective access, and we hear that ArcGIS Pro has much better support for editing feature services, but that's still rather far away...

Martin

[JerryGarcia]

SOIs allow alteration of server requests; not at the database tier.  This may work for ArcGIS Server clients.  But, will not be a solution for editors working directly from ArcMap to Enterprise GDB. How many tables do you have?  Just wondering...  What industry are you working in?  Where is this implementation?

[MartinAmeskamp]

Yes, SOI is not a solution for ArcMap, but we've been looking at Pro a lot recently, and there seems to be a strong push away from direct GDB access, towards consuming feature services (for viewing and editing).

Our context is utility application. We have a rather complex custom solution on top of ArcMap (also using some Schneider Electric ArcFM functionality), and some our larger customers use their installation, expertise and manpower to provide network documentation as a service to smaller utilities. Right now, they need a separate database for each utility, since access to network documentation is fairly strictly regulated. Number of tables is fairly high, hundreds of feature classes.

Martin

PS Our main market is Germany.

[JerryGarcia]

We hope to consolidate feature classes, restrict access by AD user for services via SOI, and use GDB check-out for individual editing.  This is not optimal, but we need to reduce the number of feature classes in the GDB.